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• Add up to 540MB of hard-disk storage 

• No-Slot Solution for PS/2 Models 50z and 70 

• Hassle-free Installation 


100% IBM Compatible Processor Upgrades for PS/2s 

• Run programs up to three times faster 

• 33MHz Speed 

• Zero-Slot Solution 
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Datacard Micro Channel 
Storage and Memory Upgrade. 

Datacard is available with 85, 
127 or 209MB of bootable 16 
millisecond access storage pins 
four SIMM sockets that accommo¬ 
date up to 64MB of system RAM. 
It's all the storage and memon 
neededfor Witidaus or OS/2for as 
little as $545suggested retail. 


Multi-Function Expansion Slot Utilization. 

Datacard features four IBM-standard SIMM sockets 
for up to 16MB in 16-bit systems or 64MB in 32-bit 
systems. Existing memory 
cards can be depopulated 
cnid replaced u ith Datacard. 



Kingston Reliability. 

Datacard users enjoy the same 
reliability customers have come 
to expect from Kingston memon 
and processor upgrades. Ei^ry 
product is individually tested 
prior to shipping and supported by free comprehemive tech¬ 
nical assistance. Datacard is backed by a fiw-year warrant}’; 
the on-hoard drive is warranted for tuo years. 



Turn Your PS/2 
Into a Graphical 
Workstation. 

Most PS/2 systems 
don t have nearly 
the storage or system RAM that graphical computing 
requires. Datacard is the complete solution to OS/2 
and Witidous hardware problems all on ofie Micro 
Channel card. 





More Information. 

If Datacard sounds like the storage and memory 
solution for you, contact your nearby Kingston 
dealer or call us at (800) 835-6575. Well be 
happy’ to ansuerymr questions about Datacard or 
any of our other 625 
upgrade products. 
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Individual Product Testing. 

Every product is bench tested 
in the system for which it was 
designed. Testing with original 
equipment manufacturer 
system diagnostics assures 
absolute compatibility’. This 
rare commitment to quality 
control leads to many years 
of reliable senice. 



The Inside Name in Upgrades 
17600 Newhope Street, Fountain Valley, California 92708 (714) 435-2600 Fax (714) 435-2699 

All Trademark.^: and Registered Trademarks are of their respective holders. Kingston and Kingston Technology are Registered Trademarks of Kingston Technology Corporation. 
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Much Ado About Multimedia 


W hy has the release of OS/2* 2.1 
done so much to popularize such 
multimedia buzzwords as frames 
per second, animation quality video, and 
scalable resolution? It’s because OS/2 2.1 
is bundled with an add-on module called 
Multimedia Presentation Manager/2* 
(MMPM/2*). MMPM/2 controls and maxi¬ 
mizes the allocation of resources such as 
sound cards, CD-ROM drives loaded with 
visual images, video cassette recorders 
(VCR), and high-resolution monitors. 

To effectively use MMPM/2, it helps to 
understand how MMPM/2 addresses the 
requirements to store and play back multi- 
media elements such as audio and video 
clips. This article provides a primer on 
multimedia and clarifies the capabilities 
and limitations of MMPM/2 so that you 
can productively use the new multimedia 
features in OS/2 2.1. 

The Business Case for 
Multimedia 

Multimedia combines the interactivity of a 
computer with a natural user interface 
that includes audio, full motion video, 
and images. Many companies believe that 
combining multimedia elements with 
personal computers will help them more 
efficiently create higher quality 
communications. 

For multimedia to reach its fullest poten¬ 
tial within an organization, it must move 
beyond the limits of stand-alone technolo¬ 
gy. Multimedia should be considered a 
corporate asset and a vital competitive 
edge-both of which may be maximized 
when multimedia is shared throughout an 
organization. To reach this level of coop¬ 
eratively sharing multimedia-enhanced 
communications, a solid framework is 
required. OS/2 2.1 is the first operating 
system designed for personal computers 
to provide such a foundation. Before 
describing OS/2’s multimedia technology, 
I’ll first outline some background informa¬ 
tion about the storage requirements for 

4 


multimedia’s audio and video elements so 
you can better appreciate OS/2’s multime¬ 
dia features. 

Multimedia’s Big Appetite 

Exploiting multimedia’s contribution to 
traditional application software has 
become possible with the combination of 
fast microprocessors, high capacity/high 
speed hard disks and CD-ROM drives, and 
image compression techniques. All these 
new technologies are necessary to store 
and manage large multimedia objects such 
as sound and video. For example, a 500- 
page textbook requires 1 MB of storage. 
Ten fax-quality images require 640 KB, 
whereas 10 detailed or color images 
require 75 MB. Five minutes of uncom¬ 
pressed voice quality audio requires 
2.4 MB of storage; the same quantity 
and length of premium quality audio such 
as compact disc or digital audio requires 
52.8 MB. 


Multimedia should be 
considered a 
corporate asset.. 


Digitized video requires the greatest stor¬ 
age capacity of all data forms. Without 
compression techniques, practical storage 
of digital video is impossible. For exam¬ 
ple, animation quality video requires 
147 MB per minute for a one-quarter size 
video. But with today’s compression tech¬ 
niques, this animation quality video can 
be compressed to 1.44 MB (one 3.5-inch 
diskette). A two-hour television quality 
movie can be compressed to about 2 GB 
of storage. NOTE: Television and high 
quality videos run at 24 frames per sec¬ 
ond. There is no significant increase in 
motion above 30 frames per second (just 
a perception of greater details such as 
color). Generally, the minimum speed at 


which humans can perceive full motion is 
15 to 16 frames per second. 

Most solutions for delivering large 
amounts of data, video, and sound to the 
desktop PC have centered on hardware 
solutions such as specialized video 
adapters for playing back the compressed 
video images. While many of today’s pop¬ 
ular software-only techniques for com¬ 
pressing and decompressing video may be 
attractive because of their low cost, the 
video quality of these algorithms is typi¬ 
cally lower than the hardware-based algo¬ 
rithms. Digital video producers have 
struggled with trading off lower quality 
and cost of software-only techniques for 
the higher quality and cost of hardware- 
assisted video. However, the software-only 
algorithm landscape has significantly 
changed with the introduction of the 
Ultimotion* technology in MMPM/2. 

Ultimotion 

Ultimotion is IBM’s software-only solution 
for playing back compressed video data. 
While a video image’s frame rate, output 
resolution, and color characteristics are 
determined when the video is created, the 
characteristics of how the video is pre¬ 
sented to the viewer depend on the capa¬ 
bilities of the playback platform. In turn, 
playback capabilities depend on several 
factors such as the type of microprocessor, 
display driver, video adapter, and data 
bandwidth available during playback. 

Ultimotion compression algorithms orga¬ 
nize the data in a video file so that it can 
be easily scaled up or down by factors of 
two as it is decompressed. Furthermore, 
as the data is decompressed, a sufficiently 
powered playback system can duplicate 
the data during output and display the 
video at four times its original size. This 
results in an effective output size larger 
than the input size. In this way, 

Ultimotion can be scaled down on systems 
incapable of processing the authored 
video resolution and scaled up on systems 
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with more processing capability than the 
authored video requires. 

For example, when using IBM's Ultimotion 
compression techniques, MMPM/2 pro¬ 
vides a standard resolution of 320 x 240 
at 15 frames per second. This is currently 
four times the resolution of typical soft¬ 
ware-only video solutions such as Video 
for Windows* from Microsoft*. This mini¬ 
mal Ultimotion movie can be played on at 
least a 25 MHz 80386* microprocessor 
and a SuperVGA adapter. Computers with 
a 33 MHz 80486* microprocessor can dis¬ 
play 320 X 240 resolution at 24 frames 
per second or 640 x 480 resolution at 15 
frames per second. 

While Ultimotion is scalable at playback 
time (from 15 to 24 frames per second or 
higher and from 320 x 240 to 640 x 480 
resolution), the amount of information 
encoded in the data stream (file) when it 
is created determines scalability. The 
amount of data initially captured in the 
data stream determines the maximum 
playback characteristics that a particular 


stream can achieve. In turn, the process¬ 
ing capabilities of the playback system 
determine how much of the data can be 
processed and presented during playback. 

The speed of CD-ROM drives and the 
amount of data that can be transferred 
over a local area network (LAN) cable (the 
network bandwidth) often constrain the 
playback platform. Full motion video at 
15 frames per second seems to be the cur¬ 
rent limit of popular CD-ROM and LAN 
technology. The current speed of most CD- 
RO.M drives limits the frames-per-second 
speed; therefore, it is generally preferable 
to display smaller frames with lower reso¬ 
lutions as they contain less data than larg¬ 
er frames with higher resolutions. 

Since most corporations will probably 
store video and audio objects on a 
main file server for delivery through LANs 
to individual users at their ow’ii worksta¬ 
tions, the average speed of 15 frames per 
second for full motion video is consistent 
with the speed of many current LAN 
adapters and wiring installations. 


Ultimotion's approach to adapt what the 
viewer sees during playback to the power 
of the playback system is a reasonable 
approach, given the limits of current tech¬ 
nology. Furthermore, Ultimotion gives pri¬ 
ority to the audio data to ensure that it 
stays in sync with the video; if necessary, 
it will decrease the frames-per-second 
speed. 

The above-mentioned requirements for 
effectively using video, sound, images, 
and text in multimedia systems of the 
1990s are well beyond anything ever 
imagined during the 198()’s design of DOS 
and Microsoft Windows. 

Word processors, spreadsheets, and most 
other popular application software must 
patiently wait until another application 
has yielded control of the CPU. 

Multimedia applications generally cannot 
wait for the CPU because the longer the 
wait, the lower the quality of the multime¬ 
dia presentation. It would probably be 
very disconcerting if the sound of a 
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printer 
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again.” 


OK, maybe LAN managers and 
systems programmers aren’t 
always this cordial. 

That’s why we’ve introduced 
VPS®/PC and DRS/PC, two new 


Introducing 

VPS/PC and DRS/PC,the new 
Host to LAN and LAN to Host 
printing solutions for 
network users. 

products designed specifically for network users. 

VPS/PC lets mainframe output print anywhere in your local area net¬ 
work, while DRS/PC lets LAN output print anywhere on your host 
printing facilities. Use them in tandem and you can share print files 
throughout the entire corporate environment: the ultimate enterprise 
printing solution. 

VPS/PC and DRS/PC offer more flexibility than anything else on the 
market—and they’re priced per copy, not per printer. 

But maybe the best thing about these products is that once they’re 
installed, LAN administrators can make changes on the network with¬ 
out making more work for their good friends in the data center. 

Try VPS/PC and DRS/PC —for more printing options and 
fewer hassles. 
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warranties with respect to this product. 


See what VPS!PC and 
DRS/PC can do for you. 
Call 217-793-3800 and 
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tennis racket hitting a ball could not be 
heard at the same time as the video clip 
displaying the racket hitting the ball- 
even if the delay was only a few seconds. 
The DOS operating system just cannot 
support this need for multitasking and 
priority scheduling. 

OS/2 is Well Suited to 
Multimedia 

Currently, MMPM/2 is not integrated 
within OS/2 2.1 in the same way that 
Windows* 31 support is integrated. The 
main installation procedure for 
OS/2 2.1 lets you choose whether or not 
to install Windows 31 support along with 
many other options. However, the installa¬ 
tion of MMPM/2 is not managed by the 
main OS/2 2.1 setup program. A separate 
multimedia install program, titled 
MINSTALL, must be used. In fact, during 
the first production run of the OS/2 2.1 
retail package, the MMPM/2 extensions to 
OS/2 2.1 were packaged on diskettes with 
different colored labels. 

MMPM/2’s superiority over other multime¬ 
dia environments is largely derived from 
several of OS/2’s advanced memory man¬ 
agement features, described below. These 
features combine to provide audio and 
video lip sync, for example, in a manner 
that surpasses other desktop operating 
environments. 

OS/2 2.1 uses pre-emptive multitasking to 
simultaneously play back video clips and 
sound bites, thereby emulating the lifelike 
quality of TV shows and movies. Pre-emp¬ 
tive multitasking enables the CPU-such as 
an Intel* 80386 or 80486 chip-to effec¬ 
tively manage playing back both a video 
segment on the graphics card and a sound 
segment on the sound card simultaneous¬ 
ly. In contrast, cooperative multitasking 


techniques used by systems such as 
Microsoft Windows assume that software 
developers (or video image and sound 
bite providers) will adhere to the same set 
of rules for sharing the CPU. Multimedia 
applications cannot wait patiently on line 
for their turn to move through the CPU to 
reach the sound or graphics card. 

Protected memory prevents system fail¬ 
ures that result when one application cor¬ 
rupts the memory space used by another 
application. Flat memory addressing 
allows OS/2 to handle the many 
megabytes of data that compose the 
graphic and sound objects associated with 
multimedia applications. System perfor¬ 
mance is significantly enhanced when the 
operating system can juggle large files in 
one step rather than in smaller chunks. 

The OS/2 2.1 environment enables new 
features, devices, and data objects to be 
added to the MMPM/2 environment as 
new hardware and software products 
come to market. 

MMPM/2 Features 

MMPM/2 features and functions are cate¬ 
gorized in the following three groups: 
device drivers, mini-applications, and mul¬ 
timedia subsystems. 

Device drivers control add-on hardware 
products such as CD-ROMs or sound and 
graphic adapters. OS/2 2.1 contains 
drivers for popular products such as the 
Creative Labs Sound Blaster*, the Media 
Vision Pro Audio Spectrum l6* sound 
cards, and the Hitachi*, NEC*, Sony*, and 
Toshiba* CD-ROM drives. 

MMPM/2’s multimedia mini-applications 
allow you to immediately experience 
some of the potential offered by adding 


sound, video, and audio to your comput¬ 
er systems. For example, the CD Player 
enables standard audio compact discs to 
be played on supported CD-ROM players. 
The Digital Audio Player allows digitally 
recorded audio, such as the Sound Bites 
included in MMPM/2, to be played 
through one of the supported audio 
cards. 

The multimedia subsystem functions 
provide common services needed by a 
range of multimedia applications such as 
those in which you need to ensure that 
video or audio data is reproduced 
smoothly on the screen or speaker. One 
such component is the Media Control 
Interface (MCI), an easy-to-use description 
language that allows you to take even 
more control of multimedia hardware 
(such as CD-ROM players) than is avail¬ 
able through using the mini-applications 
described above. 

Conclusion 

In both corporations and homes, multi- 
media computing is fast becoming an 
integral part of the everyday desktop 
computing environment. OS/2 currently 
provides the best solution for meeting 
the demanding storage and playback 
requirements of multimedia on personal 
computers. 

Steven Levenson, a consultant to software 
and hardware vendors in the LAN and multi- 
media markets, is a 10-year veteran of the 
computer industry. He holds a PhD in 
Instructional Technology from New York 
University and has written several books on 
networking and OS/2, including Now That I 
Have OS/2 2.1 On My Computer. What Do I 
Do Next? 
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PERFORMANCE 2.1, 

A Tuning Kit for OS/2 2.1— 

A Ciear and Simple Solution to 
Your OS/2 Tuning Needs 


OS/2 Vendor Council 


C lear and Simple’s PERFORMANCE 
2.1, A Tuning Kit for OS/2 2.1, 
guides users (both novice and 
advanced) through OS/2 tuning proce¬ 
dures with an instructional book and a 
diskette containing 30 helpful REXX utili¬ 
ties. This kit demystifies the task of opti¬ 
mizing your system by not only showing 
you which commands and parameters you 
can change to enhance your OS/2 perfor¬ 
mance, hut also providing utilities to help 
you do it. 

Are you a novice? 

If you’re a novice, the hook’s Basic section 
is written just for you. It clearly describes 
the OS/2 concepts you need to fine tune 
your system. You’ll read about “32-bit- 
ness,” multitasking, multithreading, virtu¬ 
al memory, FAT vs. HPFS, thrashing, and 
disk fragmentation. 

Are you an advanced user? 

If you’re an advanced user, refer to the 
book’s Detail section for tips, techniques, 
parameters, and commands you’ll use to 
tune your system. Some Detail topics 


T ony Pereira, developer of Clear 
& Simple, Inc.’s PERFORMANCE 
2.1, A Tuning Kit for OS/2 2.1, 
recently devised a way to gain expo¬ 
sure for his OS/2 application. He 
formed the OS/2 Vendor Council, a 
group of OS/2 developers who want 
to promote their products. The group 
intends to increase the exposure their 
applications receive in software and 
computer retail stores and mail order 
outlets through cooperative advertis¬ 
ing with retailers. 

To help fund the campaign, Tony has 
joined forces with IBM’s Personal 
Software Products group to split the 


cost of a six-month ad campaign that 
will feature OS/2 Shopper Pages in 
several major computer magazines. 

The ads will describe the OS/2 Vendor 
Council products and list the names of 
retailers and mail order outlets that 
carry the suite of OS/2 products. 
Retailers have agreed to create OS/2 
shelf space in return for a mention in 
the ads. 

Vendors interested in joining the OS/2 
Vendor Council must be currently 
shipping a horizontal OS/2 applica¬ 
tion. For more information, contact 
Tony Pereira by phone at (203) 658- 
1204 or by fax at (203) 651-0354. 
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* Maintenance 


REAL-TIME 

TECHNOLOGIES 

1001 Greenbay Road 
Winnetka IL 60093 

(708) 380-3584 
Fax (708)446-6886 



Please circle #18 on reader service card. 
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Figure 1. PERFORMANCE 2.1 Icon View Window 


Optimizer routines assess your system 
and recommend CONFIG.SYS parameters, 
then optionally update your settings. 

Eliminators relieve fixed disk space. 

Save up to 15 MB of disk space for those 
OS/2 features you don’t use or need. 

Tools update individual CONFIG.SYS 
parameters accurately to help you tune 
individual parts of your system. Some 
tools provide information; others perform 
specific tasks. 


OSPBOOT 


jThis program will create a bootable diskette for OS/2 2.1. 

; Label it •’PERFORMANCE 2.1 OS/2 BOOT Diskette" 

It will also (optionally) create a second diskette containing several 
(Utility functions that can only be run when you are booted from the 
Boot Diskette. 

Label it the "PERFORMANCE 2.1 UTILITY Diskette". 

See the Software Chapter in the Booklet for more information. 

You will need up to two (2) blank, formatted, High Density 3.5" diskettes. 

(one for the OS/2 Boot Diskette and .one for the Utility Diskette.) 

(or one 2.88MB diskette) 

■jYou will also need the OS/2 2.1 INSTALLATION diskette and OS/2 2.1- Diskette 1 
jif you want to build an OS/2 Boot Diskette, 

jDo you have the necessary items and wish to continue? (Y/N) 


Figure 2. 0S2B00T Initial Screen 

include caching, buffering, timeslicing, 
thread priority, task switching, fragmenta¬ 
tion, and more. 

How can you simplify your 
tuning efforts? 

Simplify your tuning efforts with the 30 
utilities that come with PERFORMANCE 
2.1. These utilities, written in the easy to 
learn and modify REXX language, provide 
you with source code sample programs 
that access and manipulate OS/2 objects. 
Figure 1 shows all 30 program icons con¬ 


tained in PERFORMANCE 2.rs Icon View 
window. 

Even the PERFORMANCE 2.1 Setup pro¬ 
gram is a valuable REXX program exam¬ 
ple for creating folders, shadows, and pro¬ 
gram objects for your Workplace Shell* 
desktop environment. Plus, these utilities 
come with over 3,000 OS/2 format icons 
as an added bonus. 

The utilities that come with PERFOR¬ 
MANCE 2.1 include the following: 


Performers include 0S2B00T, an object 
that creates a diskette containing a mini¬ 
mal OS/2 system you can use to boot 
OS/2, allowing for disk checking plus 
backup and recovery. Figure 2 shows the 
first screen you see when you activate this 
program. Other Perfomers include pro¬ 
grams that measure and report on your 
tuning progress, back up your OS/2 
Workplace Shell desktop, and reset icon 
associations. As an added bonus, the pack¬ 
age includes over 3,000 public domain 
OS/2 format icons. 

You can purchase PERFORMANCE 2.1 
from Clear & Simple for only $29.95. 

They accept VISA, MasterCard, and 
Discover credit cards, plus company pur¬ 
chase orders. PERFORMANCE 2.1 can also 
be ordered as an IBM publication (SR28- 
4641). 

For more information about 
PERFORMANCE 2.1, contact 
Tony Pereira 
Clear & Simple, Inc. 

P.O. Box 130 

West Simsbury, CT 06092 

Ph. (203) 658-1204 
Fax (203) 651-0354 
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Point of View 

Some Enthusiastic Users 
Speak Out About OS/2 


T he OS/2 Bulletin Board System 

(BBS) has become a favorite meeting 
place for proponents of OS/2 (see 
sidebar). The following quotes are from 
OS/2 BBS participants who have agreed to 
share their favorite OS/2 features in this 
issue’s “Point of View.” 

Workplace Shell— 

A Good Decision 

The WPS [Workplace Shell] is what 1 like 
best about OS/2 2.1. It lets me be me and 
not some propeller head, command-line 
jockey. And furthermore, the Workplace 
Shell is based on the SOM [System Object 
Model], making it easy either to use WPS 
methods as-is or to modify WPS methods 
in your application to tailor the behavior 
of WPS to fit your requirements. 

IBM made a very risky decision to include 
WPS in OS/2 2.0. This decision is really 
paying off now. While the recently 
released 32-bit operating system competi¬ 
tor is very good for a first release and is 
bound to get even better, the competition 
will be hard pressed to match WPS and 
SOM in the next 18 to 24 months. And 
OS/2 won’t be standing still during this 
time. - Bob Holmes 

Making Believers 
Out of Doubters 

Back when the WPS was introduced dur¬ 
ing the early OS/2 2.0 beta cycle, many, 
many people were screaming (myself 
included. I’m afraid) about what a stupid 
move this was on Boca’s [Boca Raton, 
Florida is the site of IBM’s OS/2 develop¬ 
ment team] part and asking how we get 
back the 1.3 desktop and performance. 

Can anyone imagine OS/2 2.x without 
WPS? The thought makes my skin crawl. 
Talk about boring, hamstrung, and brain 
dead! - Dick Kurtz 


Programs Run Better 
Under OS/2 

The thing I like about OS/2 is that I don’t 
have to give up all my existing programs 
in order to run it. What’s more, my pro¬ 
grams generally run better under OS/2 
than they do natively (go figure...). I use 
a mix of DOS, Windows, and OS/2 stuff 
every day-and, by gosh, it all works. In 
fact, I did away with my Boot Manager 
DOS partition a long time ago. I still have 
a DOS floppy for when I want to run 
Mathcad* 4.0, but that’s about the only 
thing I use it for any more. 

- Bob Beilstein 


. . .OS/2 increases my 
productivity by at least 
25%. . .probably more. 


True Multitasking 

I’ll agree the WPS is probably the neatest 
thing since beer. It really makes it easy to 
work. For me, the best feature of OS/2 is 
its true multitasking ability. For example, 

I was working at home on an OS/2 appli¬ 
cation I’m developing for our operations 
staff (I can’t get an upgrade to my work 
machine approved, so I’m being gracious¬ 
ly allowed to write at home). 

I had one modem hooked up to work for 
E-mail (windowed session); the other was 
tied into the IBM OS/2 BBS picking up a 
file I needed. I also had a background 
compile going on, an editor session in a 
foreground window, and the last two ses¬ 
sions that were open were for creating 
the help and INF [information] documents 


to go with it. Flitting around working on 
different things as I need to or while a 
long task is running saves me time and 
just makes my life easy! 

Then, too, when the usual happens and 
my son comes downstairs with a floppy in 
his hand because he needs to print a file, 
he doesn’t have to wait and I don’t have 
to quit OS/2-the only way to go! 

- Harold Clitheroe 

Increases Productivity 

As a corporate user, I can honestly say 
that OS/2 increases my productivity by at 
least 25%, very probably more. I need to 
multitask between many applications 
(DOS, Windows, native OS/2, host, X 
Windows*, and network) in order to per¬ 
form my job, and OS/2 allows me to do 
this without wasted effort and time. Just 
as with voice mail and E-mail before it, I 
didn’t think that using OS/2 would be a 
very big deal. But now it wouldn’t be 
pleasant to contemplate attempting to do 
my job without it. - Lee Butkiewicz 

Genuine New Technology 

OS/2 represents “genuine” new technolo¬ 
gy, especially in SOM and WPS. 

OS/2 runs nearly all DOS and Windows 
software as well or better than DOS and 
Windows themselves. 

CUA* ’91 is far more flexible than the 
Windows interface and its many imitators 
(from Microsoft Word* 5.5 to the Norton 
Utilities*)-no wonder, seeing that the 
Windows interface hasn’t changed materi¬ 
ally since 1985. (Program Manager is 
much more advanced than MSD0S.EXE, 
but that’s not the same thing.) 

The OS/2 applets are genuinely usable. 

So far I haven’t seen any need to invest in 
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Bulletin Boards: An IBMer’s Point of View 


here are only two types of peo¬ 
ple in this world: those who 
use the OS/2 Bulletin Board 
System (BBS) and those who don’t! 

According to a report on National 
Public Radio’s program “All Things 
Considered,” over a million people in 
the United States log on to electronic 
bulletin board systems every month. 
No question about it, these BBSs 
have arrived with a vengeance. You 
can find BBSs for social mingling, for 
industry experts, for political prefer- 
ences-if you have an interest, there 
is probably an electronic BBS where 
you can “meet” with fellow devotees. 

So it comes as no surprise that there 
would be an OS/2 BBS. The only sur¬ 
prises might be how inexpensive it 
is, how useful it is, and how much 
fun it is! 

On the first point, the OS/2 BBS is 
available for a low S18 a month for 
TalkLink users, no matter how many 
times you call or how long you stay 
connected. 

As for usefulness, consider this: how 
useful is it to ask for OS/2 tips and 
techniques from the most knowledge¬ 
able people in our industry, both 
inside and outside of IBM? I continue 
to marvel at the number of quality 
responses BBSers get when they ask: 
“Has anyone tried...?” or “What hap¬ 
pens when 1...?” 

While not a true service or support 
offering, it is not unusual to get a 
reply from a developer who is active¬ 
ly working in the area about which a 
BBS user is inquiring. BBSers also 
benefit from sharing information 
with their peers around the world- 
people running the same kind of 
application, using the same equip¬ 
ment configuration. 

As an IBM employee, one of the 
things that pleases me about the 


OS/2 BBS is the improved flow of 
communication between IBM and our 
customers. Before I begin a project, 
through completion, and on into the 
evaluation process, 1 can maintain a 
dialog with customers. This dialog 
helps me determine requirements, 
then understand how well my pro¬ 
grams support the intended audience. 
Without question, the quality of my 
work has improved because of 
improved communication with my 
customers! 

IBM participation on the OS/2 BBS 
goes beyond that of developers and 
technical staff. Recently a customer 
noted that his company had a meeting 
to discuss information technology 
strategy. There was a point of confu¬ 
sion regarding IBM’s position on an 
issue. That question received a 
response from Jim Cannavino, IBM 
vice president and general manager, 
who presides over the IBM PC 
Company and the IBM Personal 
Software Products Division, stating 
IBM’s position and offering to help 
clear up the matter. Because 
Cannavino’s reply, “The IBM 
Corporation definitely has OS/2 as 
part of our long term strategy,” was 
posted on the OS/2 BBS, customers 
and IBMers alike were able to quickly 
understand IBM’s strategy and share 
his comment with others. 

The fun of being on the OS/2 BBS 
comes from the folks who use and 
support the bulletin board. The BBS is 
a community of people dedicated to 
helping each other exchange informa¬ 
tion and solve problems. This means 
people get to know each other-to 
form friendships. And they electroni¬ 
cally share their jokes and sense of 
humor! 

BBSers have a language all their own. 
A short while ago, a typo received 
acceptance as a new word describing 
an activity, a skill, or, for some devo¬ 
tees, even a hobby. The typo occurred 



when BBSers were discussing watch¬ 
ers, or people who read the bulletin 
boards but never participate. After the 
typo incident, it was not unusual to 
read someone asking, “Exactly what is 
a ‘wather’?” 

A new family of acronyms, sort of a 
BBS shorthand, has evolved. IMHO (in 
my humble opinion), OTOH (on the 
other hand), and BTW (by the way) 
are some of the most frequently used 
abbreviations. 

BBSers have also invented a new 
series of abbreviations and illustra¬ 
tions to apprise the reader of the state 
of mind of the author. To warn read¬ 
ers that what has just been said is 
tongue-in-cheek, an author may termi¬ 
nate a thought with “G,” “BG,” “VBG,” 
or even “VVBG” to indicate “grin,” 

“big grin,” “very big grin,” and so on. 

Victor Borge gave us “spoken punctua¬ 
tion,” but BBSers have given us hori¬ 
zontal happy faces: 

:-) grin 

:-> big grin 

8 ) grin with sunglasses 

:-( sad 

;-) grin with “knowing wink" 

So, as promised, BBSs provide infor¬ 
mation, help, and fun-all for the 
monthly cost of a movie for two (that 
is, unless you are like me and frequent 
the $1 movie-G)! This thing can't 
miss! When you get on the ()S/2 BBS, 
don’t forget to say hello to all the 
wathers and lurkers. I'll be looking for 
you! TTFN (ta ta for now). Bob. 

Bob St. John is a long-time IBMer 
and member of the Technical 
Coordinator Program staff in IBM 's 
Personal Computer Competency 
Center in Dallas. He provides an 
important link between customers 
and the Technical Coordinator 
Program, gathering requirements 
and reviewing proposed offerings. 
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a PIM [personal information 
manager], a terminal program, or a text 
editor-although all these categories are 
well-represented in OS/2. 

REXX is a joy to use. A fully functional 
programming language that serves as the 
system batch language, REXX automates 
much system customizing (this could he 
better, though), and easily becomes the 
macro language of any application. It’s 
almost impossible to live without once 
you have it. 

As a computer programmer and system 
programmer since 1965,1 know from 
experience that the basic design of OS/2 
is right, whereas the basic designs of DOS 
and Windows 3.1 are wrong. (UNIX* and 
Windows NT* share this with OS/2, of 
course.) 

Over against UNIX, my main points (apart 
from WPS and REXX) would be that OS/2 
is better suited, both in scale and in user 
interface, to a personal computer, that 
UNIX is being architected only after the 
fact, and that, in large part, OS/2 can be 
described as a single-user UNIX designed 
with hindsight. 

Over against Windows NT, my main 
points (apart from WPS and REXX) would 
be better DOS and Windows 3.x support, 
OS/2 1.x PM [Presentation Manager*] and 
OS/2 2.x application programs, better 
price, and better performance. 

-John W. Kennedy 

Good Corporate Applications 
Available 

OK, here’s my "top of my head” list: 

• Excellent backwards compatibility 
(both DOS and Windows) 


• Ability to run multiple protocol 
stacks (and to easily install them) 

• Object-oriented desktop 

• Good support 

• CID [configuration, installation, 
distribution] 

• REXX (especially now with the V- 
REXXs [visual REXXs] out there) 

• Capable desktop and server 
operating system-makes building 
client/server applications easier 

• Many good corporate applications 
available (i.e., ImagePlus*, etc.). 
Admittedly, we could use a few 
more “personal” applications, but 
the first point helps a lot here 

There’s my two minutes worth. 

- Erik Vander Ahe 

Making Computing More Fun 
and Productive 

Multitasking. Hands down. 1 went from 
DOS 3.21 on an XT to OS/2 I.l on an AT, 
skipping Windows completely. The thing I 
remember most about DOS is waiting: 
printing, downloading, formatting, etc. 
The first time 1 sat down at a machine 
running Windows, 1 had been using OS/2 
2.0 for about six months. Imagine my sur¬ 
prise when Windows couldn’t run two 
DOS programs simultaneously! Until then, 
1 saw Windows as a competitor to OS/2; 
after that, 1 saw it as just another pretty 
interface. Today, not only am 1 happily 
multitasking among my programs; I now 
have programs that multitask within 
themselves, making sitting at the comput¬ 
er much more fun and productive. 

- Gerald Meazell 


Database Manager for the 
Non-Database Person 

I’ve been using Database Manager (now 
DB2/2*) for a couple of years now at 
home. 1 had no background in relational 
databases before, but I can tell you that 1 
think it’s fantastic. Every friend of mine 
who has seen it in action has switched 
from other SQL products. With the Query 
Manager, 1 put together a rather compli¬ 
cated database for an international ski 
race that we held early this year in 
Germany in a matter of a few days. 1 can 
really recommend it, especially because of 
the ease in which a non-database person 
can put together professional applications 
in a very short time. - Tom Clark 

Just Plain Fun 

I’ll give you my two favorites and two or 
three bonuses. 

The Workplace Shell 

1 love it. A friend received a new comput¬ 
er the other day for his son who is going 
off to college. Of course this clone came 
with Windows on it, but he wanted me to 
help him check it out. When I booted it 
up, there was Windows 3.1. Ten minutes 
later I realized two very important things: 

• First, Windows programs have much, 
much better interfaces than does 
Windows itself; and, 

• Second, it takes trying to check out a 
system under the Windows interface 
to realize just how great the WPS 
truly is. 1 kept clicking that right 
mouse button to see what something 
was and kept getting nothing in 
return. 

Of course, there is a downside to the 
simplicity and power of the WPS. My wife 
is ready for a new computer, and she has 


The PC Connection to AS/400, RS/6000, ES/9000 & 4680 

The 3164 Emulator PC Software 


3164 Color Terminal Emulation 
3151, 316x Terminal Emulation 
Complete Keyboard Mapping 
28x132, 28x80, 25x80 Display 
National Language Character Sets 
Play/Record Keys 
Line Speeds to 38400 bps 
Printer Emulation 
Runs Under PC DOS 


The 3164 Emulator is a PC communication program 
that emulates IBM's 3164 ASCII Color Display Station. 
It runs on IBM and compatible PC's. The software 
provides display terminal and printer emulation, 
providing the user with both an interactive session and 
the abilty to receive reports and other printed output 
at the PC. ^ ^ ^ ^ 

$ 119 . 0 “ 

Satisfied customers around the world. 



PRODUCTIVITY SYSTEMS, INC. 
9330 W. LINCOLN AVE. 
MILWAUKEE, WI53227 
PHONE: (414) 321-8688 
FAX: (414) 546-8499 


Please circle #19 on reader service card. 
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told me not to even think of getting any¬ 
thing that won’t run OS/2. And her rea¬ 
son isn’t stability, multithreading, or 
multitasking. It is the WPS. She says it’s 
the only thing about computers she ever 
saw that made any sense to someone who 
doesn’t love computers. 

Multitasking 

I’ll just echo what everyone else says: 
until you’ve had the ability to multitask, 
you can’t possibly appreciate what mar¬ 
velous ways it will change the way you 
use your computer. Maybe this little anec¬ 
dote will be illuminating. 

I just set up my sister, the math professor, 
with a new 486 running OS/2 2.1. She has 
written a couple of math texts, actually 
understands the definition of “limit,” and 
teaches the mathematics of programming 
languages. On the other hand, she is 


having a hard time remembering that she 
has a right mouse button. 

The other day we were checking out her 
modem and new OS/2 communications 
software. As she only has one line, we 
were in chat mode, going over what she 
needed to do to download some files from 
my computer. On my suggestion, she had 
configured the package to put download¬ 
ed files into F:\transfer. Suddenly she 
types: “Oh, no! I forgot to create the direc¬ 
tory. I’ll have to log off, and. ..” 

It took a bit of typing over her explana¬ 
tion before I got her attention. “You’re 
multitasking now, dear,” I said. “Just go 
make your directory. It’s no problem. I’m 
reading my E-mail now anyway.” 

Later she called me back. “What’s all this 
killer app stuff?” she wanted to know. 


“Who needs it? There are lots of nice 
applications. Now there is a great operat¬ 
ing system to run them.” 1 agreed with 
her. The last thing she said was, “Why 
would anyone not run OS/2? It’s amazing.” 
My sentiments exactly. 

The Third Thing 

Well, those are my two favorite things 
about OS/2. My third favorite is some¬ 
thing I’ve almost forgotten about: 1 don't 
need to try to use and configure memory 
managers like QEMM. I love the way OS/2 
handles printers, runs DOS apps, lets me 
use the mouse in a DOS window, handles 
icons, MMPM/2, and on and on and on. 
Heck, I’ve even gotten so that I like 
Drives! Oh yeah, there’s one other thing. 
OS/2 2.1 is just plain fun to use. 

- Stan Hawkins 


Team OS/2 —K Groundswell of 
Support for OS/2 


Y ou may have heard of Team OS/2, 
but you might not fully understand 
what it’s all about. Don’t feel bad-I 
started it, and I still don’t think I fully 
understand the phenomenon. I’m certain 
1 don’t know everything about every 
Team OS/2 activity. Literally thousands of 
enthusiastic volunteers are now part of 
this “happening.” I do know, however, 
that Team OS/2 has been fueled by the 
creativity and imagination of many thou¬ 
sands of OS/2 enthusiasts in their pursuit 
of quality, synergy, and positive relation¬ 
ships. That’s worth trying to understand, 
and I think you’ll find it’s also worth get¬ 
ting involved. 

The Beginning 

Team OS/2 has been around, in spirit at 
least, from the time OS/2 was first con¬ 
ceived by teams of IBM and Microsoft 
visionaries and programmers looking to 
replace DOS with a far more capable 
operating system. It wasn’t until February 
12, 1992 that it took a recognizable form 
when I created TEAMOS2 FORUM on 
IBM’s internal bulletin board. I dedicated 
the forum to “the discussion of those 
things that empowered IBMers, working 

PERSONAL SYSTEMS • JANUARY/FEBRUARY 1994 


as a team, can do to promote the success 
of OS/2. The focus here is, through team¬ 
work, creating synergy and combining tal¬ 
ents to achieve results greater than the 
sum of individual efforts.” 

The only requirement for membership has 
been that an individual “make a personal 
sacrifice, however small, to help others 
recognize that OS/2 can be the foundation 
for the next generation of personal com¬ 
puting.” At the time Team OS/2 began, 
OS/2 2.0 was available as beta code in a 
limited release, enabling a lot of people to 
experience some of the features that have 
since made OS/2 such a hit: 

• Multitasking that really works 

• The powerful but easy Workplace 
Shell user interface 

• The ability to run more PC 
applications than any operating 
system or environment in the 
industry 

OS/2 users knew that OS/2 was the 
underdog in what many perceived as a 
“war” between OS/2 and DOS/Windows, 


even though anyone who bought OS/2 
got DOS and Windows as well. These 
users wanted to share their love of OS/2 
with others, and that’s how Team OS/2 
got started. 

The Concept 

Since the beginning, Team OS/2 has gone 
wherever Team members have taken it 
and has become whatever Team members 
want it to be. Throughout the world there 
are thousands of Team members from a 
wide variety of OS/2 user communities- 
both within and outside of IBM. Many of 
us have found that using OS/2 and com¬ 
puter communications networks has 
helped us make friends we might other¬ 
wise not have made. It has also given us 
an opportunity to actually put into prac¬ 
tice such ideals and principles as a respect 
for others and a willingness to help oth¬ 
ers. We don't expect anything in return 
beyond the intrinsic satisfaction that 
comes from sharing what we value. 

Team OS/2 volunteers have done some 
amazing things and have a lot to show for 
their enthusiasm: 
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THE COMPLETE DATA COLLECTION MANAGEMENT SYSTEM 


Bridge.Net, today’s link to tomorrow’s data collection needs. A 
software product that provides a complete platform-independent 
graphics development environment for creation, modification, 
simulation, and debugging of applications for DOS, 

UNIX, and AS/400 environments. 

A series of run time modules then permit that appli¬ 
cation to execute on any of the mid-range, PC, or 
portable platforms on which the software resides 
without having to change a line of code. 

Bridge. Net performs real time data collection from 



simple to complex stations or networks; provides connectivity 
of dissimilar and otherwise incompatible devices; serves as a 
multi-protocol communications gateway; enables separate 
program control on each individual port; supports 
centralized or distributed processing; and has LAN 
and WAN compatibility. 


•NET 



It Is based on real world needs and solves real world 
problems. Contact us today for complete details. 
Vertex Industries, Inc.,23 Carol Street, Clifton, NJ 07014. 
(201) 777-3500. Fax: 201-472-0814. 
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Wait ’til 

Want to make sure your OS/2® LAN Server com¬ 
patible application is a certifiable success? Start 
the ball rolling by having it 
certified through one of our 
three certification programs. 

^ Companies that want to 
test their own products can choose 
from two self-certification options. 

All self-certified products receive 
’ the ‘‘Ready! for LAN Server” 
for LAN Server seal of approval, giving your 
customers the peace of mind of knowing it was 
tested for LAN compatibility. 

For assurance of compatibility 
with all IBM LAN platform products, 








see 


send your product to our Integration Test 
Lab. Using a combination of hard¬ 
ware and software products to 
recreate typical real-world environ¬ 
ments, we’ll test and certify 

your product for ■ you. After 




for LAN Systems 


Program Overview 

Ready! 

for LAN Server 

Tested and Approved 
for LAN Systems 

What’s Tested 

Your product with 

LAN Server 

Your product with 

LAN Server, NetWare,* CM/2, 
DCE, LAN NetView,* etc... 

Who Performs 

You 

IBM Integration Test 

Lab personnel 

How Measured 

Ready! for LAN Server 
Certification Guidelines 

Comprehensive 
test suites 

Where Tested 

Your lab, or the Mini-LAN 
lab in Austin, Texas 

Integration Test Lab 
in Austin, Texas 

Technical Support for 
Your Customers 

You provide support 

A cooperative support 
arrangement with IBM is 
automatically available 



reviewing our findings, we’ll award your prod¬ 
uct the “Tested and Approved for LAN 
Systems” certification mark. 

Whatever certification option you choose, 
we’ll help draw even more attention to your 
products. Using highly visible communications 
channels, we’ll spread the word to hundreds 
of thousands of users. To find out more about 
our Product Certification programs, call 
1 800 992-4777. To your customers, it could 
be just what it takes to help seal the deal. 

^ We’re in the business 
I of connecting yours. 



IBM, OS/2 and NetView are registered trademarks of International Business Machines 
Corporation. NetWare is a trademark of Novell Corp. © 1993 IBM Corp. 


















• Organizing user group 
demonstrations 

• Adopting software stores (explaining 
OS/2 to dealers and sales personnel) 

• Setting up booths at fairs 

• Demonstrating OS/2 to college 
professors and classes 

• Organizing roving OS/2 help squads 
to assist vendors in booths at 
COMDEX*, PC EXPO*, and other 
trade shows 

• Working with PRODIGY* and IBM to 
improve the presence of OS/2 on 
PRODIGY 

• Setting up a Team OS/2 echo on 
FidoNet 

• Writing shareware or other 
application software for OS/2 

• Negotiating the terms under which 
IBM employees can release their 
personally developed OS/2 software 
for general use 

• Helping members of the media 
understand OS/2 

• Getting together with others who 
use OS/2 to trade tips and 
experiences 

• Starting, supporting, and joining 
OS/2 user groups and special interest 
groups 

• Participating in and running OS/2 
bulletin boards and online 
conferences 

• Demonstrating OS/2 to new users 
and encouraging others to try OS/2 

• Writing letters to magazines to 
correct misunderstandings 

There have been some exciting times and 
great moments for Team OS/2. At the first 
Team OS/2 party at COMDEX in April, 
1992 , the key developers of OS/2 got 
together with independent software ven¬ 
dors (ISVs), OS/2 customers, marketing 
personnel, and others to share the excite¬ 
ment of the long-awaited release of the 
32-bit OS/2. IBM executive John Soyring, 
an inspiration to many Team OS/2 mem¬ 
bers, said it was the first reception he had 
ever attended that gave him goose bumps. 
The Chicago jazz band members were so 
impressed by what they saw happening 
that they stood in line with everyone else 


Becoming a Team 
OS/2 Member 


T o let Others know you are part of 
Team OS/2 and to have your 
name included in the list we 
maintain, contact one of the following: 

• CompuServe*: Vicci Conway at 
76711, 1123 

• Internet*: teamos2@vnet.ibm.com 

• FidoNet: Janet Gobeille at 
1:109/347.3479 

• IBMMAIL: USIB45RN at IBMMAIL 

• Fax: Team OS/2 Support at 
(512) 823*3252 

Please include your name, mailing 
address, phone number. E-mail 
address, and a one-line description of 


your ties to and interest in OS/2. (Your 
mailing address and phone number 
will not he published on any distribu¬ 
tion list.) Please include your experi¬ 
ences with OS/2 and your successes in 
sharing OS/2 with others, plus any¬ 
thing else you want to share relating 
to your OS/2 “qualifications.” 

We will put your name, city, state, E- 
mail address (of whatever system you 
include in your application), and 
description in the public Team OS/2 
list, available on the electronic bulletin 
boards. Your address and phone num¬ 
ber will be added to our Team OS/2 
database and used only for any neces¬ 
sary future contact, such as Team OS/2 
mailings. 


to get their Team OS/2 and “ibm/2” 
T-shirts. 

The T-shirt was inspired by TEAM0S2 
FORUM participants who asked for a 
T-shirt they could wear to identify them¬ 
selves as empowered members of Team 
OS/2. The “ibm/2” logo suggests a “new 
IBM” that respects “the little guy” as well 
as individual empowerment and initiative. 
The “/2” emphasizes the ties between 
OS/2 and this new IBM. 

The Commitment 

Today, Team OS/2 is open to anyone who 
wants to be a part of all of this, whether 
you work for IBM or not. IBM Personal 
Software Products executives (who also 
claim membership in Team OS/2) have 
agreed to support Team OS/2 activities, 
including occasional Team OS/2 recogni¬ 
tion receptions (usually at Fall COMDEX). 
IBM has a department to respond to 
requests for assistance from Team OS/2 
members and to support these grassroots 
marketing efforts, which have been such a 
key part of 0S/2’s success. 

Team members are familiar with the 
delightful presence of Vicci Conway and 


Janet Gobeille, two members of IBM’s 
grassroots support department, on the 
electronic forums and at Team OS/2 hospi¬ 
tality suites at trade shows and confer¬ 
ences. Many of the customers featured in 
this issue’s “Point of View” article are 
enthusiastic members of Team OS/2. 


IBM recognizes that all association with 
Team OS/2 is purely voluntary and that 
there are no mutual expectations or 
future dependencies. IBM and other com 
panics or individuals with an economic 
interest in OS/2 are part of Team OS/2 
under the same terms as all members- 
with no strings attached and with com¬ 
plete respect for the freedom of others 
and their right to choose their level of 
commitment and participation. 


At the foundation of Team OS/2 are the 
concepts of quality, imagination, respect, 
relationships, and teamwork. We don’t 
bash DOS or Windows or other companies 
or individuals. We understand and appre¬ 
ciate the uniqueness of each individual. 

We don’t take ourselves or OS/2 so seri¬ 
ously that we become fanatics. And, final¬ 
ly, we try to maintain a sense of bumor 
and balance about what we do. 
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If you choose to become a Team OS/2 
member, your participation can take what¬ 
ever form you choose, consistent with the 
above concepts. You are free to use the 
words ‘Team OS/2” to let others know 
you are part of this worldwide team. 

When you say you are a part of Team 
OS/2, you signal to others that you are 
willing to help them understand and use 


OS/2 better. As a Team OS/2 member, you 
agree not to detract from or dilute the 
name Team OS/2 by using it in conjunc¬ 
tion with activities that disparage or 
embarrass others. 

Thanks for your interest and participa¬ 
tion. Here’s to a bright future with OS/2, 
you, and Team OS/2! 


Dave Whittle, located in Austin, Texas, not 
only represents IBM Personal Software 
Products (PSP) on the networks and bul¬ 
letin boards, but also represents the inter¬ 
ests of those on the networks and bulletin 
boards to PSP. He is the author of PS/2 
Reference Tables and co-author of 
Dvorak’s Guide to OS/2 Version 2.1. He 
has a BS in accounting and an MBA, both 
from Brigham Young University. 


Manage Your LAN Systems More 
Effectively with IBM NetFinity 


Y our local area network (LAN) is a 
formidable asset. A well organized 
and managed LAN enables you and 
your staff to quickly and efficiently 
exchange data and information. By com¬ 
bining the power of your individual sys¬ 
tems, your LAN can greatly enhance your 
workforce’s productivity and performance. 

However, if the individual systems that 
make up your LAN are not managed effec¬ 
tively, the performance of your entire LAN 
can be compromised. How can you ensure 
that your LAN systems are operating at 
peak efficiency? How can you maximize 
your workstations’ power? How can your 
LAN administrator detect and resolve 
problems on individual workstations 
quickly, without wasting money in 
downtime? 

The solution is NetFinity*. NetFinity is a 
complete hardware management environ¬ 
ment designed with the user in mind. 
Combining system monitoring and man¬ 
agement features previously found only in 
costly and complicated products with the 
intuitive graphical interfaces popular 
today, NetFinity simplifies the most 
sophisticated system management tasks 
(Figure 1). 

NetFinity Services for ()S/2 VI. 1 provides 
the foundation for the NetFinity solution 
by greatly enhancing the local system 
management capabilities for both LAN- 
attached and stand-alone systems. 

NetFinity Services for OS/2 provides you 
with: 


• Powerful local system management 
capabilities 

• Useful utilities for LAN-attached and 
stand-alone systems 

• Easy-to-use graphical interfaces 

• Extensive online helps 

NetFinity Services also provides the 
framework for remote system access and 
management with NetFinity Manager for 
OS/2 Vl.l. NetFinity Manager builds on 
the power of the NetFinity Services, 
adding new utilities that enable you to 
effectively manage systems on your LAN 
from your own local system. 

NetFinity Manager for OS/2 provides you 
with: 

• Powerful remote system management 
capabilities 

• Utilities to organize and access 
individual systems and servers on 
your LAN 

• Remote access to the NetFinity 
Services installed on systems and 
servers within your network 

• Easy-to-use graphical interfaces 

• Extensive online helps 

NetFinity enables you to fully support 
your network. It can be used in a wide 
variety of network environments, using 
one or more of these common communi¬ 
cation protocols: 


• NetBIOS 

• Transmission control 
protocol/internet protocol (TCP/IP) 

• Internet packet exchange (IPX) 

Power and Flexibility 

NetFinity’s powerful information gather¬ 
ing, monitoring, and management utilities 
can also be used with IBM-compatible sys¬ 
tems from a broad variety of manufactur¬ 
ers. And, as your network expands, 
NetFinity’s system management capabili¬ 
ties can be combined with a network 
management system such as IBM LAN 
NetView* for a comprehensive network 
management solution. 

Powerful and reliable system management 
utilities are not a luxury-they are critical 
for saving time and money. The Gartner 
Group, a respected technical consultant, 
estimates that the cost of owning and 
managing a computer system over five 
years is nearly six times greater than its 
original purchase price.’ The vast majority 
of these additional costs are generated by 
the time and effort spent on system 
administration, technical support, and 
asset management. 

With NetFinity, you can tip this equation 
in your favor. By using NetFinity’s power¬ 
ful remote and local system management 
capabilities, your LAN administrator can 
troubleshoot users’ workstations, 

‘Gartner Group. 199.T 
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distribute information and software, iden¬ 
tify problems proactively, audit network 
assets, and determine how best to deploy 
equipment-all from his or her own work¬ 
station and in a fraction of the time it 
would have taken without NetFinity. 

NetFinity is both cost effective and easy 
to use, a pleasant change from most sys¬ 
tem management products available 
today. NetFinity’s intuitive graphical inter¬ 
faces enable your LAN administrator to 
intelligently monitor and manage your 
networked systems, eliminating the long 
learning curve often associated with such 
powerful functionality. With NetFinity’s 
sophisticated utilities, a LAN administra¬ 
tor can access workstations on the net¬ 
work to monitor performance, update 
code, view the screen display, and even 
run other programs from a command line. 
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Figure 1. NetFinity Service Manager 
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NetFinity’s graphical user interface 
displays each NetFinity system in your 
network as an individual icon on the 
LAN administrator’s screen. An adminis¬ 
trator can access any NetFinity service 
available on a system by simply pointing 
and clicking on the system’s icon. With 
NetFinity, you can collect system informa¬ 
tion, start applications, transfer files, and 
more with just a few simple actions. It’s 
that easy. 

NetFinity Services’ flexible, modular archi¬ 
tecture allows for a variety of system spe¬ 
cific configurations, installing only the 
program files necessary for the individual 
system’s designated function within a net¬ 
work environment or as a stand-alone sys¬ 
tem. NetFinity’s modularity also enables 
you to update the base product and add 
new services without reinstalling the 
entire product. In short, NetFinity com¬ 
bines the power and flexibility you want 
today with the expandability you’ll need 
in years to come. 

System Management 
Applications 

NetFinity Services forms the foundation of 
the NetFinity solution. NetFinity Services 
consists of seven powerful system man¬ 
agement applications, each one providing 
sophisticated local and remote system 
management functions. NetFinity Services 
can he installed on stand-alone systems, 
can he used strictly as a base program 
that enables a network administrator to 
remotely manage the system, or can 


Figure 2. NetFinity System Information Tool 

enable the local user to perform many 
system management functions locally as 
well as enabling the administrator to 
remotely manage the system. 

The NetFinity Services include: 

• System Information Tool 

Use the System Information Tool to 
detect the status of system component 
and environment variables. The tool 
reports detailed information on a 
wide variety of the systems on your 
LAN, including adapters, SCSI configu¬ 
ration and devices, disk drives, 


PCMCIA devices, memory, 1/0 devices, 
and much more (Figure 2). 

System Profile 

System Profile is a fully customizable 
user- and system-information facility. 
Use System Profile to track user- 
specific system information to more 
efficiently audit and manage assets. 

A customizable template helps you 
get started. 

System Monitor 

System Monitor displays line graphs 
and real-time graphical monitors for a 
variety of system resources including 


PERSONAL SYSTEMS • JANUARY/FEBRUARY 1994 


19 














lO© ^ 


>Uons DisplHii yelp 


I .d: 

SheH lilt' Iransler Susteni ProliJe 

@1 

1 View tgg^MiaiLcsa Alerl r'l«mii<jer 




CPU UtHi/atlon Monito 
5 % 


I 


Driv»^ C: Space Used 
MH 


Threshold Manager 


Monitor 

CPU UlilL-’ation Monitor 


I hresUoid name 


TooMuct. 

Levels 


Lrrw If above Pi 

Warning If above ;/*» 


Duration 
7 , tlifiiiios 

Kesend t>eiay 
Never 

Seveiiig 


Severity 


Notify 

✓ 


fioiily 


He(t> 


Figure 3. NetFinity System Monitor Service 
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Figure 4. NetFinity Remote System Manager 


microprocessor, disks, and memory 
usage. It also generates alerts in 
response to user- or administrator- 
specified thresholds to help proactively 
identify problems (Figure 3). 

• Security Manager 
Security Manager prevents unautho¬ 
rized access to your NetFinity Services. 
Select which Services to make available 
to which remote users or restrict access 
altogether. It generates alerts in 
response to access violations by remote 


users, enabling you to track attempts to 
access NetFinity Services. 

• Alert Manager 

Alert Manager receives and processes 
application-generated alerts (such as 
the alerts generated by the System 
Monitor and Security Manager Services) 
and enables the user or administrator 
to specify actions to be taken in 
response to the alert. Actions include 
logging the alert, pop-up notification, 
forwarding the alert to another user, 


and executing commands. The alert log 
can be examined, edited, and printed 
for use in reports. 

• ECC Memory Setup 

Error Correcting Code (ECC) Memory 
Setup enables the user or LAN adminis¬ 
trator to control the ECC memory fea¬ 
tures on many IBM or IBM-compatible 
systems. It also records the number of 
single-bit errors, enables or disables sin¬ 
gle-bit error correction, and more. 

• System Partition Access 

System Partition Access is a powerful 
access tool for IBM systems with built- 
in system partitions. The system parti¬ 
tion is a group of pre-installed utility 
programs found on many PS/2* sys¬ 
tems. System Partition Access enables 
you to update, back up, even delete 
your system partition, all without 
having to use a reference diskette to 
restart your system. 

NetFinity Manager for 
OS/2 V1.1 

NetFinity Manager for OS/2 builds on the 
power of the NetFinity Services to provide 
you with powerful remote system manage¬ 
ment capabilities, including access to all 
NetFinity Services installed on systems 
within your network, bi-directional file 
and directory transfers, remote command 
line OS/2 sessions, and remote screen 
captures. 

The NetFinity Manager includes: 

• Remote System Manager 

Remote System Manager enables your 
LAN administrator to access and con¬ 
trol all NetFinity Services installed on 
the remote systems in your network. 
Remote System Manager also features a 
keyword-based discovery process that 
enables you to automatically search for 
and group NetFinity systems on your 
LAN for easier LAN organization and 
management (Figure 4). 

• File Transfer 

File Transfer enables your LAN adminis¬ 
trator to easily send, receive, or delete 
single files, multiple files, or entire 
directories locally or remotely. 

• Remote Session 

Remote Session enables you to establish 
a fully active OS/2 window session on a 
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remote system. Use Remote Session to 
help determine problems and trou¬ 
bleshoot efficiently. 

• Screen View 

Screen View takes a “snapshot” of a 
selected remote system’s screen display. 
Use Screen View to help view and fix 
problems remotely. Screen shots can be 
saved as bitmaps and reloaded using 
Screen View for future reference and 
analysis. 

System Requirements 

The minimum system requirements for 
NetFinity client or manager systems are: 

• OS/2 2.0 (with Customer Service 
Diskette) or 2.1 

• 6 MB memory 

• Approximately 4 MB hard disk space 
for NetFinity Services for OS/2 (does 
not include Remote System Manager, 
File Transfer, Remote Session, or 
Screen View) 

• Approximately 6 MB hard disk space 
for NetFinity Manager for OS/2 

(4 MB for the NetFinity Services for 
OS/2 plus an additional 2 MB for the 
NetFinity Manager’s additional 
services and features) 

• i386SX* processor or higher 

• LAN adapter cards and one or more 
of the following communications 
protocols: 

- TCP/IP 

- NetBIOS 

- IPX 

IBM NetFinity is available in both admin¬ 
istrator (IBM NetFinity Manager) and 
client (IBM NetFinity Services) packages. 
Ask your IBM representative for further 
details, or call (800) IBM-CALL (426- 
2255) and ask for networking products 
information. 


Gregg Primm is currently working on the 
next release of NetFinity with the NetFinity 
development team In Boca Raton, Florida. 
In addition to a strong creative writing back¬ 
ground, Gregg has written a number of 
technical documents, including the online 
and hard documentation for the NetFinity 
products. He has a BA degree in English 
from the State University of New York at 
Buffalo. 


Earn $4,000 Per Month 
From Your Home 
With A Computer! 

Quit spending money on your com¬ 
puter and let it earn money for you. 
This is a proven turnkey business an 
individual or couple can run. If you 
purchase our software and business 
program, we will give you the com¬ 
puter and printer. If you already own 
a computer, you may receive a dis¬ 
count. Begin part-time and still 
retain the security of your present 
position. We will provide free home 
office training. Financing available. 

FREE CBSI 486 SX Computer 

Learn how other individuals are building a lifetime income! 

To receive your free cassettes and color literature, 
call toll-free: 

1-800-343-8014, ext. 1179 

(in Indiana: 317-758-4415) Or Write: 

Computer Business Services, Inc. 

CBSI Plaza, Ste. 1179, Sheridan, Indiana 46069 


Please circle #21 on reader service card. 



Now Shipping.... 

NDP OS/2 2 .7 
Developer’s Pack 

$595 Includes: 

•32-bit Globally Optimized Code 
•32-bit Graphics and AR Access 
•IBM Toolkit and Workframe 
•Integrated Development Environment 
•1500 pages of documentation 
•Your Choice of Compiler; 

NDP Fortran-77 
NDP CIC++ and NDP Pascal 

Call for our White Papers on OS/2, i860 Parallel Processing on 
PCs, NDP Fortran 90 and our port of LAPACK to the 486 and 
i860 - the best Linear Algebra Package for RISC processors. 

Micromy" 

Research Park Box 79, Kingstort, MA 02364 USA (SOS) 746-7341 
U.K., 081-541-5466 USA FAX (SOS) 746-4678 


Please circle #22 on reader service card. 
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Plan, Plan, Plan 

Your NetWare 4.01 Network 


The introduction of the NetWare* 4,01 network operating system into 
the PC networking arena brings with it many new and advanced fea¬ 
tures, such as security and administration, that are designed to 
improve performance. Planning your NetWare 4,01 network is funda¬ 
mental to its successful implementation. This article provides some 
guidelines for planning your network—specifically in relation to 
NetWare 4,01's NetWare Directory Services, 

T he core of NetWare 4.01 is NetWare Directory Services (NDS). NDS is a 
global, distributed, replicated database that maintains information about 
every resource on the network, such as users, groups, printers, volumes, 
and computers. With NDS, a distributed network database serves as a directory 
for all nodes on a local network or on an internetwork, which is a larger net¬ 
work (such as Internet) that extends beyond a local network. 


scenes. The result is that a large, diverse 
network of users is simplified into a sin¬ 
gle, easy-to-use environment. 

The NetWare Directory 

In NetWare 4.01, all network resources 
are set up as objects in a distributed 
database called the NetWare directory 
database. This database organizes 
resources in a hierarchical tree structure, 
independent of location. Users and admin¬ 
istrators can access network services with¬ 
out having to know the physical location 
of the server. 


Lionel Kidd 
IBM Corporation 
Roanoke, Texas 


NDS is a single, logical 
database. All users, applica¬ 
tions, and servers can access 
this database 
for informa¬ 
tion. This 
implementation 
differs from 
previous ver- 
sions of 

NetWare in that 
users formerly had to know the 
location of each resource, how 
to access the resource, and the 
permissions necessary to use 
the resource. Now, access to 
any resource or user on the 
network is done through NDS. 


With NDS, a user connects 
through a single login, sharing 
the network without having to 
understand its complexities. 

NDS hides the network 
topology, protocols, media, and 
communication links by hand¬ 
ling these things behind the 
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The directory replaces the bindery, which 
served as the system database for previ¬ 
ous versions of NetWare. The bindery con 
tained all of the information about the 
services provided by a single server. In 
contrast, NetWare Directory Services sup¬ 
ports an entire network of servers. 
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Information about the network is stored 
on more than one server, eliminating the 
risk of a single point of failure. 

For users who are non-NetWare 4.01-com¬ 
pliant, there is bindery emulation. With 
bindery emulation, the NetWare 4.01 


server looks like previous versions of 
NetWare servers. These users do not have 
the benefit of NDS. Since the structure of 
the file system has not changed, file shar¬ 
ing remains the same. 

Instead of logging in or attaching to indi¬ 
vidual servers, NDS users log into the net¬ 
work. Users enter their passwords only 
once to gain access to all network 
resources available to them. 

Network-wide access control allows a user 
who has logged into the network to 
access all servers, volumes, printers, and 
so on that the user has the right to 
access. User trustee rights restrict the 
user’s access within the network. 

Objects 

The NDS object contains a kind of infor¬ 
mation called properties. Properties con¬ 
tain information such as telephone or fax 
number, address, and physical location. 
This information is entered into the data 
fields for each property. Object properties 
are stored in the directory database. 

Some objects can represent physical enti¬ 
ties such as printers (printer objects) or 
NetWare servers (server objects), while 
other objects represent logical entities, 
such as groups and print queues. 

When a request for information about an 
object is received, NDS does a search 
based on the property selected. For exam¬ 
ple, you may only know^ a user’s tele¬ 
phone number, but you want to find the 
user’s name. You can search the database 
using the telephone-number property to 
find the object associated with the tele¬ 
phone number. That object will contain 
the name of the user. You can also search 
through all the properties for a single 
object. 

The Directory Tree 

NDS operates in a logical organization 
called a directory tree. In a directory 
tree, objects are stored in a hierarchical 
tree structure, starting with the root and 
branching out. 

Two types of objects make up the directory 
tree: container objects and leaf objects. A 
branch of the directory tree consists of a 
container object and all the objects it 
holds, which can include other container 
objects. At the ends of the branches are 
leaf objects, which do not contain any 


The country and organizational unit objects are optional, but you 
must include at least one organization object in your directory tree. 

Figure 1. Possible Configurations for a Directory Tree 


Bindery Objects I Changed To 


Users 

NDS user objects. Properties of user objects become 
login restrictions. 

File system trustee 
assignments 

Same as in NetWare 3.11 

Groups 

NDS group objects (same trustee assignments and 
security equivalences are carried over) 

Default account 
restrictions 

Carried over from NetWare 3.11 

Print queues 

Same as in NetWare 311 

Console operator 

Becomes the operator property of the server object 

Security equivalence 

Becomes the security equivalence property in the 
user object 


Figure 2. Changes to Existing Bindery Objects in NDS 
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other objects. Figure 1 shows some possible 
configurations for a directory tree. 

Thoughtful planning of the directory tree 
will: 

• Provide fault tolerance on the network 

• Decrease traffic on the network 

• Enable users to easily access 
information 


• Enable network supervisors to easily 
administer the network 

There is no single way to design your 
directory tree. Following are some guide¬ 
lines to prepare your company for 
installing NetWare 4.01. 

From Here to There 

The binderies in previous versions of 
NetWare must be upgraded to NDS. Each 


user, printer, computer, file server, etc. is 
an object in the directory tree. Figure 2 
shows the changes that are made to exist¬ 
ing bindery objects. 

The Standard Is . . . 

Over time, changes will occur in your net¬ 
work. Adding users, providing access to 
the objects, and adding function are some 
changes that will occur. Standards govern 
how these changes should happen. Figure 
3 gives an example of a standard. In 
Figure 3, all the entries collectively form a 
single standard. 

Who’S on First? 

The directory tree should reflect the struc¬ 
ture of your company. Before you install 
NDS, decide how to organize your directo¬ 
ry tree. Meet with department managers 
to determine what kind of directory tree 
organization best suits your company’s 
needs, then customize the tree to each 
department’s or group’s needs. The physi¬ 
cal and logical locations of the objects in 
your environment affect the layout of the 


Identification Property 

Vaiue 

Title 

Enter the user’s current job title. 

Department codes 

Use company department. 

Default server 

Use the server from which the user gets SEND 
messages. 

Network address 

No standard. 

Login name 

Enter the first and last name of user. Capitalize 
all letters. 

Figure 3. Sample NDS Standards for Object Properties 
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Figure 4. Sample of Full NDS Directory Tree 
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Container Object 

Abbreviation 

Description 

Country 

c 

One level below the root object, the country object designates the countries where your net¬ 
work resides and organizes other objects within the country object. For example, you could use 
a country object for the country where your organization headquarters resides or, if you have a 
multinational network, for each country that is a part of your network. 

Note. The country object is not part of the NetWare 4.01 default server installation; that 
is, NetWare 4.01 does not prompt you for a country object during installation, but you can 
create one. 

Using a country object in NDS is not a requirement for interoperability with other X.SOO-com- 
pliant directory services. 

Organization 

0 

One level below the root object (unless you use the country object, in which case the 
organization object must be one level below country), the organization object helps you orga¬ 
nize other objects in the directory tree and allows you to set defaults for user objects that you 
create in this container. 

You can use an organization object to designate a company, a university with various depart¬ 
ments, or a department with several project teams. 

The organization object is mandatory. The directory tree must contain at least one 
organization object. 

Organizational Unit 

ou 

One level below the organization object, the organizational unit object helps you to orga¬ 
nize leaf objects in the directory tree. You can also set defaults in a login script and create a 
user template for user objects that you create in this container. 

For example, you could use an organizational unit object to designate a division, a busi¬ 
ness unit, a project team, or a college or department within a university. 


Figure 5. Types of Container Objects 


Leaf Object I Description 


AFP Server Represents an AppleTalk* Filing Protocol (AFP)-based server that is operating as a node on your NetWare network (and is 
probably also acting as a NetWare router to, and the AppleTalk server for, several Macintosh* computers). 

Create this object when you have an AFP server that you need to represent on the network. Use it to store information 
about this server, such as its operators, users, and network address. 

This object has no effect on network operations; it only stores information about resources on the network. 

Alias Refers to another object in the directory tree, and makes it appear as though the object that it names actually exists in 

the directory tree where the alias is created. 

Although an object appears both where it was first created and where an alias referring to it was created, only one copy 
of the object really exists, and changes made to either object affect what appears in both locations. 

Bindery Represents an object placed in the directory tree by an upgrade or migration utility, but which cannot be identified by 

NDS. This object exists for backward compatibility with bindery-oriented utilities. 

Bindery Represents a queue placed in the directory tree by an upgrade or migration utility, but which cannot be identified by 

Queue NDS. This object exists for backward compatibility with bindery-oriented utilities. 


Computer Represents a non-server computer, such as a workstation or a router, on the network. 

Use this object to store information such as the computer’s network address, serial number, or the person to whom the 
computer is assigned. 

This object has no effect on network operations; it only stores information about resources on the network. 


Figure 6. Types of Leaf Objects 
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Leaf Object 


Description 


Directory 

Map 

Represents a particular directory in the file system. Directory map objects can be used in lieu of login scripts by point¬ 
ing to directories that contain applications or other frequently used files. 

The MAP command is a DOS command that uses a DOS drive letter as a redirector for a directory or subdirectory. The 
drive letter represents the directory or subdirectory. A search drive is a mapped drive of a directory or subdirectory that 
is searched any time a command is executed from the command line. 

Mapped drives and search drives can be executed from login scripts, which are similar to hatch files. The executables in 
the login scripts apply to each user, or groups of users, as designated within the login script. There can be one or several 
login scripts. If there is a change in the directory or subdirectory, each login script must be changed. 

For example, if you have a directory that contains DOS 5.x, you will probably map a search drive to that directory in any 
login scripts you create. Later, if you upgrade to DOS 6.x and rename the directory, you will have to change the mapping 
in every login script where that search mapping appears. 

When you use the directory map object, however, the mapping applies to all users who have rights to the object; there¬ 
fore, changes are made to the object rather than to several different login scripts, and changes can be managed more easily. 

Group 

Assigns a name to a list of user objects located anywhere in the directory tree. Use a group object when you want to 
assign rights to a group as a whole, instead of to individual users. The rights you assign to a group object are transferred to 
individual users who are members of the group, wherever they are located. 

NetWare 

Server 

Represents a server running NetWare on your network. Store information about the server in the NetWare server object’s 
properties. This is information such as the server’s location on the network wire, the physical location of the server, 
which services it provides, and so on. 

In addition to storing information about the NetWare server, the NetWare server object affects the network because sever¬ 
al other objects refer to it. For example, the directory map object points to the NetWare server object to find the directory 
it needs; the volume object points to the NetWare server object to find the physical volume of the particular NetWare serv¬ 
er. Use the NetWare server object to tie the physical server on the network to the directory tree. Without this object, you 
cannot access file systems that are on the server’s volumes. 

If you have a non-NetWare 4.01 server, you must create this object to be able to access those non-4.01 volumes. When you 
create a server object for a non-4.01 server, you enter the IPX address of the server and then create volume objects that 
refer to that server object. A physical volume name on the non-4.01 server is placed by default into the volume object’s 
properties when you name the host server to which this physical volume is attached. 

Organizational 

Role 

Defines a position or role within an organization. Create an organizational role object so that you can assign rights to a 
particular position, in which the person who occupies that position (the occupant) may change frequently but the respon¬ 
sibilities of that position do not. 

For example, you may want a Print Manager for Sales. You create an organizational role object called Print Manager and 
grant that object all object rights to the printer, print queue, and print server objects in that part of the directory tree. 

You may also grant the Print Manager object the property rights to the print job configuration property of users. The 
organizational role object Print Manager can now manage all printing in the Sales container. 

You can assign any user to be an occupant of the organizational role object, because every occupant receives the same 
rights that you granted to the organizational role object. 

Print Server 

Represents a network print server. You must create a print server object for every print server on the network. 

Printer 

Represents a physical printing device on the network. You must create a printer object for every printer on the network. 

Profile 

Contains a profile script (login script). The profile object listed as a property in a user object is executed when that user 
object logs in, after the system login script and before the user login script. 

Create a profile object for a set of users who need to share common login script commands, but who are not located in the 
same container in the directory tree or are a subset of users in the same container. 

Print Queue 

Represents a print queue on the network. You must create a print queue object for every print queue on the network. 


Figure 6. Types of Leaf Objects - Continued 
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Leaf Object 


Description 


User Represents a person who uses the network. You must create a user object for every user who must log in to the network. 

When you create a user object, you can create a home directory for that user, who will have default rights to that home 
directory. You can also choose to apply a template to that user, which will provide defaults that you have already set up. 


Objects for users with NetWare 4.01 workstations can be created anywhere in the directory tree, but users must know 
their context in order to log in. When their 4.01 workstations are installed, you can enter their context into the NET. CFG 
file, which places them in the correct context when they log in. 


Objects for users with non-4.01 workstations must be created in the container in which the bindery emulation context is 
set for the server that users need to log in to. (Bindery emulation is set by default for every NetWare 4.01 server that is 
installed.) Non-4.01 users do not need to know their context, because they log in to the server rather than the directory 
tree. 


Unknown 


Volume 


Represents an NDS object that has been corrupted and cannot be identified as belonging to any of the other object classes. 

Represents a physical volume on the network. You must create a volume object for every physical volume on the network. 
You are prompted to create volume objects for every physical volume on a server on which you install NetWare 4.01. 


In the volume object’s properties, you must store information about which NetWare server the physical volume is located 
on and the name of the volume that is recorded when the volume is initialized at the server (such as SYS:). If you create 
the volume object during installation, this information is placed in the volume object’s properties by default. In the vol¬ 
ume object, you also set restrictions for use of the volume, such as setting an owner. 

In the NetWare administrator graphical utility, you can use the volume object to display information about the directories 
and fields on that volume. 


Figure 6. Types of Leaf Objects - Continued 


directory tree. Uniformity in the 
directory tree ensures smoother 
network operations. 

Can You Be Specific? 

Design your directory tree to reflect 
how your company shares resources. 

Place NDS objects commonly shared by 
a single group together. For example, if 
you have a high-speed printer that every¬ 
one needs to access, place the printer 
object for that printer in a container 
above the containers where you place 
the user objects. Then you can assign 
rights to the lower containers to give 
everyone in those containers access to 
that printer object. 

Figure 4 contains a sample of a full NDS 
directory tree in which the high-speed 
printer is placed as a printer object in the 
marketing organizational unit. 

It is easier to grant rights at the container 
level than it is to give everyone rights to 
access a particular object. Objects can 
always be added, deleted, or moved once 
the directory tree is installed. Figure 5 
lists the types of container objects, and 
Figure 6 describes each kind of leaf 
object. 


Over and Over Again 

To be more scalable and reliable, the NDS 
database is divided into smaller portions 
called partitions. Partitions are created by 
default when you install NetWare 4.01 on 
a server in a new context in the directory 
tree. 

Each partition consists of a container 
object, all objects contained in it, and 
data about those objects. Partitions do not 
include any information about file sys¬ 
tems or the directories and files contained 
there. 

The tree of partitions is transparent to 
directory users (unless they are running 
Partition Manager); users usually see only 
a global tree of directory objects. 

To optimize access to different areas of 
the directory, each partition can be repli¬ 
cated and stored at many locations. 

Divide the NDS database at logical bound¬ 
aries. For NDS to be distributed across a 
network, the database must be stored on 
many servers. Ratber than copying the 
entire database onto the server, replicas 
of the partitions of the database are 
stored on servers throughout the network. 


A replica is a copy of a partition. You can 
create an unlimited number of replicas 
and store them on any NetWare 4.01 serv¬ 
er on the network. 

Carefully placed replicas of the partitions 
decrease traffic and access time on the 
network, because the information comes 
from the nearest available server. This is 
particularly helpful for users who have to 
gain information about the network 
across a wide area network (WAN) link. 
You can place a replica containing needed 
information on a local server. 


It’S a Matter of Time 

Crucial for operating NDS, the time syn¬ 
chronization feature establishes the order 
of events between the servers. Events 
such as password changes are time- 
stamped to enable NDS to determine 
which replicas to update and in what 
sequence. Several types of time servers 
can be strategically placed throughout the 
network; however, the most important 
one is the single-reference time server. 


The single-reference time server sets the 
correct time for the entire network. The 
network administrator determines which 
server will be the single-reference time 
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server, based upon the physical layout of 
the network. It is best to establish this 
server on the first NetWare 4.01 server 
installed, and also at the primary location 
for network administration. 

You Have the Right... 

In previous versions of NetWare, you 
could assign directory and file rights. 

With NetWare 4.01, you can also assign 
rights to objects and to object properties. 
Directory and file rights apply only to the 
file system. 

When you plan your directory tree, con¬ 
sider how to control access to objects in 
the tree. You can control access by using 
the hierarchy of the tree itself because of 
the way rights flow down through the 
tree. Use the following methods to control 
access to objects within the tree: 

• Granting trustee assignments to any 
object for any other object 

• Creating group objects to give groups of 
users limited or unlimited access to par¬ 
ticular objects in the directory tree 

• Creating an inherited-rights filter for an 
object to limit access to that object (The 


inherited-rights filter is a part of the 
properties of the object that prevents 
rights from filtering from one object to 
another. In some situations, a user 
object can automatically receive, or 
inherit, rights from another object. The 
inherited-rights filter can block any of 
those inherited rights so that the user 
object does not receive them.) 

• Making a user object the security 
equivalent to any other object 

Summing It Up 

NetWare 4.01 is an ideal solution for com¬ 
panies with numerous protocols, topolo¬ 
gies, operating systems, and workstations. 
For the user, today’s complex networks 
can be simplified into one single, logical, 
integrated view of network resources. 
Information can be stored on several dif¬ 
ferent servers, and you can find the 
desired information without having to 
search throughout the network. At the 
workstation, information that appears to 
he within your location may actually be 
many miles away. 

Planning your network with NDS is very 
important. Consult with department 
heads and network administrators when 


you are preparing to install your NetWare 
4.01 network. Detailed preparation and 
planning will ensure a smooth installation 
and an information network suited to 
your company’s needs. 
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LAD/2 in the LCU and 
NetView DIVI/2 Environments 


S uppose you have 100, 
500, or maybe 1,000 or 
more workstations to 
install and maintain. What is 
the best way to accomplish 
your task? 


Bob Bush, 

Peter Escue, 

Tom Lambert, and 
Avalyn Pace 
IBM Corporation 
Roanoke, Texas 


Which avail¬ 
able products 
or programs 
can assist you 
in performing 
these tasks? 
How much 

jjfQg ^j|| 

take to configure and install 
the software? How much train¬ 
ing or knowledge will you need 
to accomplish your goal? 



The advent of graphical user interface (GUI) operating systems has 
spawned a flood of easy-to-use, powerful applications. This power, how¬ 
ever, comes at a price: disk drive space requirements and maintain¬ 
ability. Some Windows and OS/2 programs take up to 30 MB and may 
have 12 or more diskettes! OS/2 itself has 25 diskettes and can take up 
to an hour of disk swapping to install. These large programs can take a 
toll on management information systems (MIS) personnel who have 
several hundred workstations to install or upgrade. This is where an 
installation and management tool like LAN Automated Distribution/2 
(LAD/2) is most useful. LAD/2 provides an easy-to-use Presentation 
Manager (PM) interface to the configuration, installation, and distri¬ 
bution (CLD) processes in both the LAN CID Utility (LCU) and NetView 
Distribution Manager/2 (NetView DM/2) environments. 


Obviously, installing diskettes 
manually is the most straightforward 
method, requiring no additional programs 
or products. Unfortunately, it also requires 
a lot of time and is impractical for more 
than a few workstations, because manual 
installation requires that a skilled user at 
each workstation insert and remove 
diskettes and enter the required 
parameters. 

There are many variables to consider, and 
as many solutions, depending on a given 
set of variables. We attempt to identify 
the more important variables and to offer 
a few solutions to this complex, time-con¬ 
suming effort of software installation and 
maintenance. 




In this article, we provide information to help you decide which envi¬ 
ronment—LCU or NetView DM/2—better meets your requirements. We 
discuss the requirements and 
advantages of each of these envi¬ 
ronments as well as the added 
value that LAD/2provides to each 
environment. We then present an 
installation and configuration 
scenario that shows how LAD/2 
simplifies the CID process. 










m 
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IBM has developed a process that simpli¬ 
fies installing and maintaining software 
in a LAN environment; it’s called configu¬ 
ration, installation, and distribution 
(CID). In general, the CID process enables 
you to install and configure software 
without shuffling diskettes, and it does 
not require a user at each workstation to 
enter the installation and configuration 
parameters. 

Products that implement the CID process 
are called i'AD-enahled. CID-enabled prod¬ 
ucts can be installed using images 
installed on a redirected drive located on 
a CID code server. 

A CID code server is an OS/2 workstation 
that stores the product images, response 
files, logs, and any other required data. 
The CID code server also contains the nec¬ 
essary software (LAN transport, redirect¬ 
ed drive support, and controlling mecha¬ 
nism) to support CID installations. The 
CID strategy has also defined a standard 
subdirectory structure for the code server. 

CID-enabled products can also process 
their installation and configuration 
parameters from an ASCII text file (called 
a resp07isefile) that can also be located 
on the CID code server. 

Two IBM solutions provide the necessary 
support for CID installations: LAN CID 
Utility (LCU) and NetView DM/2 2.0. 

LAN CID Utility 

LCU is a component of the Network 
Transport Services/2 (NTS/2) 1.0 product. 
NTS/2 is shipped with the LAN Server 3 0 
product but can also be purchased sepa¬ 
rately. The other components of NTS/2 
are the server installable file system 
(SRVIFS) and LAN adapter and protocol 
support (LAPS). 

All three components are necessary to 
support CID installations in liglitly 
attended mode. LCU installations are said 
to be lightly attended because they 
require each workstation to be booted 
from diskette to initiate the installation. 
Because the client starts the installation 
process, an LCU installation is also called 
a putt solution. 

SRVIFS provides the redirected drive 
support that allows the client workstations 
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Figure 1. LAN CID Utility and NetView DIVI/2 Positioning 
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Figure 2. LAD/2 Version 4.0 Features and Capabilities 


to access files located on the CID code 
server. LAPS provides the LAN transport 
support (NetBIOS). LCU provides 
CASAGENT support, which controls the 
CID installation process. 


LCU requires that you define an LCU com¬ 
mand file, which is a REXX command pro¬ 
cedure specifying which products to 
install, in which order to install them, 
and the required parameters (target direc¬ 
tory, location of the images, response file, 
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and so on) for invoking the product 
installation. You must also build the 
response files required to install each 
product on each client, and you must 
store the response files in the appropriate 
directories on the server. 

LCD is supported only in the OS/2 envi¬ 
ronment; it does not support installations 
to DOS clients. Furthermore, it is a LAN 
solution; LCU does not support installa¬ 
tions or distributions in a wide area net¬ 
work (WAN). In LCU, while updates are 
being made to the client, the workstation 
is not available to the user. Finally, there 
is no tracking of the change management 
other than in the LCU and product logs, 
which record the installation and are 
stored on the CID code server. 

NetView DM/2 2.0 

NetView DM/2 2.0 Extended also imple¬ 
ments the CID process. NetView DM/2 pro¬ 
vides its own redirected drive support and 
controlling mechanism for the CID process. 

Each client workstation and server must 
have a copy of NTS/2 for the LAN trans¬ 
port support (NetBIOS) provided by LAPS. 

NetView DM/2 supports CID installations 
in unattended mode, meaning that you 
do not need boot diskettes to install at 
client workstations. There is an exception, 
however: the pristine installation of new 
workstations. For a new workstation, you 
must initially boot the computer with the 
two boot diskettes created by the LAD/2 
code server. After the computer is booted, 
the installation runs unattended, 
installing all selected products. 

NetView DM/2 provides an agent, which is 
constantly running at the client worksta¬ 
tion, that waits for installation commands 
from the NetView DM/2 server (which is 
also the CID code server). Because the 
server initiates the installation, this pro¬ 
cess is called a push solution. 

All change management processes (instal¬ 
lations, updates, etc.) are recorded in a 
database and can be tracked by client and 
by product. You can schedule NetView 
DM/2 installations for specific times, such 
as during off peak hours or overnight. 

NetView DM/2 lets you define the infor¬ 
mation needed to build change profiles, 
which define the product installation 
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commands, target directory, response 
files, source image location, and so on. 
The profiles are then built into change 
files, which are database objects. You can 
then select these objects for installations 
on selected clients. You must also build 
the response files that you require to 
install each product on each client, and 
you must store the response files in the 
appropriate directories on the server. 

Which Solution Meets 
Your Requirements? 

Figure 1 presents the information you 
should use to decide which solution best 
meets your requirements. As you read the 
information, ask yourself the following 
questions: Do I need a tracking process 
for software installed on my clients? Do I 
require unattended installations? Do I 
need DOS support? What does my budget 
allow for? Choose the solution you need, 
and then see how LAD/2 simplifies the 
process. 

LAD/2 

LAD/2 simplifies the CID process by help¬ 
ing you set up the code server, providing 
centralized configuration, automating 
response file generation, and building the 
procedures necessary to control the instal¬ 
lation. In addition, LAD/2 supports 
non-CID-enabled application distribution 
and configuration for both OS/2 and DOS. 

LAD/2 provides a PM interface to the CID 
process. LAD/2 depends on the CID func¬ 
tions (redirected drive support, CID con¬ 
trol procedures, and NetBIOS support) 
provided in either the LCU or NetView 
DM/2 environment. Upon that base, 

LAD/2 builds an interface to help you cen¬ 
trally configure and automate the CID 
tasks that you normally do manually. 

LAD/2’s CID code server setup procedure 
creates the proper CID code directory 
structure and helps you load the product 
images on your server. Without this func¬ 
tion, you would have to be familiar with 
each product’s image loading procedure 
and the CID code server directory setup. 
(See the related article in this magazine, 
“Easy Setup of CID Code Servers.”) 

In both the LCU and NetView DM/2 envi¬ 
ronments, LAD/2 allows you to select the 
products to install on a set of clients. 
LAD/2 then provides a PM interface that 
lets you to define the products’ installa¬ 
tion and configuration parameters. 


LAD/2 also allows you to configure 
parameters at the client level for each 
client-specific product, such as locally 
administered addresses (LAAs), machine 
names, node ID, and CP names. LAD/2 
also provides special functions for parti¬ 
tioning, formatting, and creating Boot 
Manager partitions. Using this informa¬ 
tion, LAD/2 generates a client-specific 
response file for each product selected 
and stores the response files on the code 
server, where clients can access them dur¬ 
ing installation. If all this were done man¬ 
ually, it would be a very tedious, time-con¬ 
suming process! 

In the LCU environment, LAD/2 generates 
the LCU REXX command procedure, 
which defines which products to install, 
the parameters necessary to invoke the 
installation, and the order of the installa¬ 
tion. This procedure is based on the prod¬ 
ucts that were selected for installation 
through the LAD/2 product screen, on the 
CID requirements for controlling the flow 
of the installation, and on the product defi¬ 
nitions for each product. Normally, you 
have to manually create this procedure. 

In the NetView DM/2 environment, LAD/2 
generates the change profiles and change 
files for the products being installed. 
LAD/2 also generates a REXX command 
procedure that invokes the installation of 
the products on the selected clients. 
Without LAD/2, you would not only have 
to know the CID definition requirements 
for each product, but also know how to 
create change profiles and change files 
within NetView DM/2. 

LAD/2 updates CONFIG.SYS, 
STARTUP.CMD, and the desktop on client 
workstations. LAD/2 has a special func¬ 
tion to send customized desktops to client 
workstations. 

In addition to supporting CID installations, 
LAD/2 also supports the distribution of 
OS/2, DOS, and Windows applications to 
an OS/2 client. The scenario below discuss¬ 
es how LAD/2 handles these applications. 
Figure 2 lists LAD/2’s features and 
capabilities. 

Scenario 

Let’s look at a scenario in which LAD/2 
could be used. 

Joe owns an industrial rock gravel pit, and 
business is booming. Joe realizes that his 


old computer systems are not solid 
enough for the 1990s, and he must 
upgrade his existing computers with a 
more robust operating system. Joe decides 
to upgrade to an OS/2 platform on all of 
his new and existing workstations. 

Joe’s biggest concern is providing a 
smooth transition from the existing DOS 
platform to the new OS/2 platform. He 
needs to ensure that all workstations 
maintain connectivity to his IBM AS/400*, 
IBM LAN Server, and Novell NetWare 311 
systems. The order-takers in his company 
require a special ordering and inventory 
application that resides on both the 
Novell NetWare server and their personal 
workstations. 

Most of Joe’s 90 workstations are IBM 
PS/2s, but some are Compaq* worksta¬ 
tions and others are Dell* workstations. 

All of the workstations are connected to 
the LAN via the token-ring topology. 

Joe wants to install the following products 
on the workstations: 

• OS/2 2.1 

• NTS/2 LAPS 

• Communications Manager/2 1.01 

• Novell NetWare Requester for OS/2 

• Inventory Plus (on order-takers’ work¬ 
stations only) 

Joe has three choices for migrating his 90 
workstations from DOS to OS/2 2.1: He 
can (1) install from diskettes, (2) perform 
a native CID installation, or (3) perform a 
LAD/2 CID installation. After evaluating 
the options, Joe decides to purchase 
LAD/2 to perform his current and future 
installations over the LAN. 

By selecting LAD/2 as his installation tool 
of choice, Joe can select and install addi¬ 
tional products as his business grows. For 
instance, when a new version of 
Inventory Plus is released, Joe can install 
the application on his code server and 
send the application down to all of his 
order-takers’ machines in a matter of 
hours. 

LAD/2 provides a PM interface for the 
configuration, installation, and distribu¬ 
tion from a LAD/2 CID code server to 
client computers. Once the client 


computers start the installation process, 
Joe can go home and return the next 
morning to find all of his computers 
installed and configured the way he 
defined them in the LAD/2 PM interface. 

He can specify whether to install or 
migrate to OS/2 via the LAD/2 interface. 
If Joe selects to install his workstations, 
he can: 

• Partition and format the clients’ hard 
drives 

• Install Boot Manager on the client 
computers 

If Joe selects to migrate his workstations, 
he can: 

• Migrate to OS/2 from DOS and give his 
employees the option of booting in 
DOS or OS/2 

• Migrate the existing configuration files 
on each workstation 

Communications Manager/2 (CM/2) 
is Joe’s choice for installing 5250 
connections to the AS/4()(). Through 
LAD/2’s ability to centrally configure 
workstations, Joe can define several 
parameters-such as the number of ses¬ 
sions, session names, host name, and PlI 
name for each client-all at the LAD/2 
code server. 

Currently, Joe’s company uses Novell 
NetWare for its LAN solutions; however, 
Joe wants to migrate from NetWare to 
IBM’s OS/2 LAN Server 3-0. He is nervous 
about abruptly switching from one LAN 
operating system to another, so both 
servers will run until he is comfortable 
with the conversion. Because of the 
dual-server environment, Joe needs to 
install LAN Requester, as well as Novell 
NetWare Requester for OS/2, on all 
clients. 


Furthermore, Joe also wants to remotely 
install and tune his LAN Server 3.0 
Domain Controller. He can enter all of the 
definitions for the Domain Controller, 

IBM LAN Requester 3 0, and NetWare 
Requester for OS/2 (including NET . CFG) 
into the LAD/2 interface, and all of the 
products will be installed as defined. 

Joe also wants to remotely install two 
applications. The first is IBM LAN 
Network Manager, which will be installed 
on his workstation so that he can manage 
the LAN. LAN Network Manager is 
CID-enabled. The second is Inventory 
Plus, which will be installed on all of the 
order-takers’ workstations. Inventory Plus 
is not CID-enabled. 

For CID-enabled applications, Joe must 
input the installation parameters to 
remotely install these products. For non- 
ClD-enabled applications, he must change 
the CONFIG.SYS and STARTUP.CMD files. 
He must also enter a definition into the 
LAD/2 interface for placing an object on 
the Workplace Shell for non-CID-enabled 
applications. 

A final requirement is that the OS/2 desk¬ 
tops must be configured the same way on 
all the computers. LAD/2 can handle this! 
To take advantage of this function, Joe 
must install an OS/2 computer via 
diskette or LAD/2; configure the 
Workplace Shell exactly as he wants it 
replicated throughout his company; then 
use LAD/2 to copy the Workplace Shell for 
the configured computer to the LAD/2 
code server. After performing these steps, 
Joe can specify in LAD/2 to copy this desk¬ 
top to any or all of his client computers. 

Working with LAD/2 

LAD/2 organizes information into group¬ 
ings called customers and work groups. 
Customers are the highest level of the 
hierarchy and can have several work 



Figure 3. New Work Group Screen 


PERSONAL SYSTEMS • JANUARY/FEBRUARY 1994 













Figure 4. LAD/2 - OS/2 Product Selection Screen 
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Figure 5. LAN Server 3.0 Screen 

groups. A work group is a logical group¬ 
ing of clients that have similar base con¬ 
figurations. Basically, all the clients in a 
work group have all of the same products 
installed and use the same type of adapter. 
Nearly all parameters for the products can 
be configured at a client level. 


To start the LAD/2 process, Joe must create 
the following customer and work group: 
Customer Name: JOES 
Work Group Name: GRIT 

Figure 3 shows the LAD/2 screen to add a 
new work group. 


After a new customer and work group are 
defined, LAD/2 presents Joe with the 
main screen for configuring his clients. At 
first, this screen has only a single button 
other than the standard OK, Cancel, and 
Help buttons. This button is labeled 
Products. By selecting the Products but¬ 
ton, Joe can define which products to 
install on the clients in this work group. 
Figure 4 shows all of the available options 
on this screen. 

Since, however, Joe does not need all of 
these products for his GRIT work group, 
he selects the following: 

• OS/2 2.1 (install) 

• NTS/2 LAPS (install) 

• Communications Manager/2 (install) 

• LAN Server 3 0 (install) 

• NetWare Requester for OS/2 (install) 

• Applications (install) 

After selecting the above products, Joe 
presses OK and returns to the main con¬ 
figuration screen, where an additional 
button, called the Work Group button, 
now appears. This button leads to a set of 
screens that enables Joe to define all of 
the default client parameters for every 
product selected for this work group. 

For Joe’s GRIT work group, buttons 
appear for OS/2, LAPS, Communications 
Manager/2, LAN Server 3.0, NetWare 
Requester, and Applications. Joe can enter 
any of these screens to define the com¬ 
mon configurations of each product for all 
of the clients in the GRIT work group. For 
instance, he can configure OS/2 parame¬ 
ters such as default printers, fonts to use, 
type of mouse support, display, 
DOS/Windows support, and so on. 
Everything that Joe can configure during 
a diskette installation, he can also config¬ 
ure at the LAD/2 code server. 

If Joe selects to install OS/2 instead of 
migrating, the Partition/Format button 
appears. This button allows Joe to parti¬ 
tion two C: primary drives (only one of 
which can be seen at a time, hence only 
one C: reference), and three extended 
drives (D:, EF:). The first primary drive 
and all of the extended drives can he for¬ 
matted as either HPFS or FAT, in any 
combination. 
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For the LAN Server 3-0 product, Joe needs 
to define the default parameters for the 
GRIT work group. The domain name to 
which Joe wants all of the clients to 
attach is LADDOM. In addition, on the D: 
drive, Joe wants to install the requester 
code and the following components: 

• Fault Tolerance Administration 

• LAN Services Installation/Configuration 

• LAN Online Reference and Help 

• LAN Command Reference 

• LAN Glossary 

• Full-Screen Interface 

Joe also wants to automatically start the 
requester, messenger, and pop-up services. 
Figure 5 shows one of LAD/2’s LAN Server 
3.0 screen. 

NTS/2 LAPS must also he configured for 
this work group. Since Joe’s company uses 
the token-ring topology for its system con¬ 
nectivity and uses IBM’s token-ring 
adapter cards, Joe must configure LAPS to 
use the proper protocol. Upon entering 
the LAPS screen, Joe must define whether 
to use locally administered addresses 
(LAAs) or universally administered 
addresses (UAAs). Joe must also select to 
use the token-ring card, and he can edit 
the NetBIOS, IEEE 802.2, and NTS/2 proto¬ 
col support within the LAPS screen. 

Figure 6 shows the LAD/2 interface for 
defining LAPS. 

Once Joe has configured LAPS, he can con¬ 
tinue to the NetWare Requester panels. 

Joe has the option of selecting the target 
drive, the network interface card to use, 
SPX (sequence packet exchange) support, 
NetBIOS support, support for DOS/ 
Windows, source routing, and support for 
named pipes. In addition, Joe can also cre¬ 
ate a NET. CFG that all clients in the GRIT 
work group can use and distribute. Joe 
selects to install the NetWare code on the 
C: drive, to use the OD12ND I driver, to 
install Source Routing support, and to 
provide a NET.CFG file. 

From the Applications screen, Joe can con¬ 
nect to a computer that has the custo¬ 
mized desktop that he wants to replicate 
on all of his clients. Once connected, Joe 
uses LAD/2 to copy the desktop to the 
LAD/2 directory structure. In addition to 
selecting the desktop configuration, Joe 
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Figure 6. LAN Adapter and Protocol Configuration Screen 



Figure 7. LAD/2 Application Selection Screen 


can add the CID-enabled and non-CID- 
enabled applications on this screen for all 
clients to use (see Figure 7). To install the 
applications, Joe must go through the 
application screens to define LAN 
Network Manager as a CID-enabled appli¬ 
cation and Inventory Plus as a non- 
CID-enabled application. 

Finally, Joe needs to define the Commun¬ 
ications Manager/2 defaults and the 5250 
and APPN parameters. Once he defines 
this information, he can continue to the 
client portion of LAD/2. 

This concludes Joe’s configuration at the 
work group level. 


By pressing OK on the Work Group 
screen, Joe again sees the main configura¬ 
tion screen, which now displays the 
Clients button. Before entering the Clients 
screen, Joe must specify the number of 
clients (from 1 to 75) he wants defined in 
his GRIT work group. After he specifies 
this number, Joe must move to the client 
screen. At this time, default parameters 
are being generated for each client, based 
on information presented in the work 
group screens and pre defined defaults. 

If Joe specifies that he wants to automati¬ 
cally start the LAN Requester 3 0 service 
in the LAN Server 3 0 screen, this value is 
automatically given to each client. Within 
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Figure 8. Client Details Screen 


the client screens, any of these parame¬ 
ters can be changed on a client-by-client 
basis. 

On the other hand, Joe may decide to 
define some common 5250 definitions 
(such as Partner LU name) for all clients 
to use. In this case, more information 
such as Local LU name is required at the 
client level. Since the Local LU name must 
be unique for each client, LAD/2 gener¬ 
ates a default of AOOOl to A0075 for each 
client. Any of these parameters can also 
be changed at the client level. 

Figure 8 shows the kinds of information 
that can be modified at the client level 
within LAD/2. 

When all of the client configurations are 
complete, Joe must create two OS/2 boot 
diskettes for each client. LAD/2 provides 
an interface to do this. Based on the ver¬ 
sion of OS/2 being installed and the type 
of LAN adapter selected from the LAPS 
screen, Joe can create the OS/2 installa¬ 
tion disk and a modified diskette #1 by 
pressing the Create button on the Client 
Boot Diskette screen. 


After all of the boot diskettes are created, 
Joe must press the Generate button on 
the main configuration screen to create 
all of the necessary files for remotely 
installing all of the clients in the GRIT 
work group. After all of the files are gen¬ 
erated, LAD/2 presents the Install/Dis¬ 
tribute screen. 

By entering the Install/Distribute screen, 
Joe can start the LAD/2 CID code server. 
Once the CID code server is started and 
active, Joe can use the client boot 
diskettes created by LAD/2 to boot his 
client computers and start the installation 
process. 

From this point, Joe does not need to 
touch any client computers until the 
installation process is complete. Then all 
he needs to do is retrieve the diskettes 
from each client workstation. 


How to Order LAD/2 

You can order LAD/2 through IBM’s As-Is 
Software Products and Offering (AISPO) 
program, by contacting your IBM repre¬ 
sentative, or by calling (800) 547-1283. 
Ask for program number 5764-031. 
Optional installation and/or technical 
support services are available. 

Bob Bush is a senior 
marketing support rep¬ 
resentative in the IBM 
Personal Systems 
Competency Center in 
Roanoke, Texas. Since 
joining IBM In 1966, 
Bob’s positions have 
included finance indus¬ 
try specialist and 
AS/400 conversion specialist. Bob joined the 


Peter Escue is an 
associate marketing 
support representative 
In the IBM Personal 
Systems Competency 
Center in Roanoke, 
Texas. He joined IBM 
In 1993 to become part 
of the team developing 
LAD/2. 

Tom Lambert is an 
associate marketing 
support representative 
in the IBM Personal 
Systems Competency 
Center in Roanoke, 
Texas. He is responsi¬ 
ble for developing CID- 
SETUP and LAD/2. He 
joined IBM in 1991 
after earning a bachelor’s degree in business 
administration from the University of North Texas. 

Avalyn Pace is a mar¬ 
keting support repre¬ 
sentative in the IBM 
Personal Systems 
Competency Center in 
Roanoke, Texas. She 
is a member of the 
team developing 
LAD/2. Avalyn joined 
IBM in 1983. 
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LAD/2 group in 1991. 
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LAN Automated Distribution/2 
(LAD/2) saves network managers 
and system integrators 

■ time ■ effort ■ money 


Time is money and LAD/2 can help you 
save both. Installations with LAD/2 take 
significantly less time than the old “diskette 
shuffle.” 


LAD/2 makes complex installations simple. LAD/2 
can install and distribute your operating systems 
and applications over multiple workstations—with 
custom configurations. Use LAD/2 right out of the 
box or have our technical experts install it for you. 


“This laddie 
has better uses 
for his time 
than shuffling 
diskettes!” 

Frugal ‘LADie’ 
MacDougal 


LAD/2 NOW SUPPORTS 

• OS/2* 2.1 

• NetView DM/2* 

• OS/2 2.0 

• LAN Server 3.0 

• DOS/Windows** 

• CID enabled and non-CID 

• Comm l\/lgr/2* 1.0 

enabled OS/2, DOS, and 

• DBM/2* OS/2 

Windows programs 


Just call 1 800 547-1283, ext. 824 
and ask about our 
free trial program. 

LAN Automated Distribution/2 




frugal (froo'gal) 
adj. Economical, 


Do the frugal thing—call 1 800 547-1283, ext. 824. 






























Easy Setup of 
CID Code Servers 


LAN administrators can use the CIDSETUP utility to set up either a 
server installable file system (SRVIFS) or a LAN Automated 
Distribution/2 (LAD/2) configuration/installation/distribution (CLD) 
code server, CIDSETUP, a tool developed by the IBM Personal Systems 
Competency Center (PSCC) in Roanoke, Texas, enables you to set up a 
code server in less than four hours, (The manual setup method would 
take about one week,) 


able to install CID code servers on top of 
Novell NetWare, transmission control pro¬ 
tocol/! nternet protocol (TCP/IP), and 
NetView Distribution Manager/2 (NetView 
DM/2) servers. CIDSETUP is constantly 
being updated to support all IBM 
CID-enabled products. Figure 2 shows the 
products that are currently supported via 


CIDSETUP. 

This article describes how to install the server code, how to apply the 

product diskette images, and how to build client boot diskettes. Building Survurs 


Tom Lambert 
IBM Corporation 
Roanoke, Texas 


How can this 
tool save you 
so much time? 
It’s because 
the PSCC has 
already invest- 
——— ed the time 

and effort in 
learning how to set up a code 
server, using all of the right 
commands for copying the 
images from the product 
diskettes to the proper CID 
directory structure on your 
code server. All you have to do 
is have the product diskettes 
available during setup, then 
click on an icon. 


CIDSETUP can currently install 
SRVIFS and LAD/2 code servers. 
In the future, CIDSETUP will be 



Currently, CIDSETUP can define and 
install both LAD/2 and SRVIFS CID code 
servers. This program not only installs 
and configures the required files, it also 
creates the required CID directory struc¬ 
ture. The directory structure that 
CIDSETUP creates is the same for both 
LAD/2 and SRVIFS code servers. To he 
specific, CIDSETUP creates a \CID 


CLDSETUP is offered to customers as4s, with no LBM support either 
expressed or implied. 


Y ou’re ready to set up your CID code server. You have this new utility 
called CIDSETUP. You have the product diskettes ready. You click on 
an icon. 


That’s all! CIDSETUP takes care 
SRVIFS.INI files and your 
two client boot diskettes for 
OS/2 2.x (Figure 1). 


of the rest for you. It even creates your 
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directory as the root directory of ail files 
accessible by the client machines. The 
response file, log file, command file, prod¬ 
uct image, executable, dynamic link 
libraries (.DLLs), applets, and sample 
directories are created under \CID for the 
clients to share. 

If you are installing a LAD/2 code server, 
CIDSETUP calls the LAD/2 installation 
program. (LAD/2 is not included with 
CIDSETUP, so make sure that you have the 
LAD/2 installation diskettes before using 
CIDSETUP.) The LAD/2 program installs 
all the LAD/2 files, modifies the system 
configuration files, and places LAD/2 
icons on the desktop. While defining your 
code server, keep in mind that you must 
install LAD/2 on the same drive as the 
product images. (See the LAD/2 article in 
this issue of Personal Systems for more 
information.) 

If you are installing a SRVIFS code server, 
CIDSETUP helps you define your 
SRVIFS.INI file and builds your client 
boot diskettes. ClDSETUP’s PM interface 
supports virtually all configuration infor¬ 
mation for the SRVIFS. INI file. Figure 3 
illustrates which values you can define. 

Don’t worry if you are not familiar with 
the values in Figure 3. CIDSETUP provides 
defaults that work for most installations; 
however, if you would like more informa¬ 
tion about the configuration parameters 
in Figure 3, refer to the IBM Network 
Transport Services/2 Redirected 
Installation and Configuration Guide 
(S96F-8488). 

After specifying the SRVIFS information 
in Figure 3, you can specify which redi¬ 
rected drive the clients can use to access 
the aliases defined in the SRVIFS. INI 
file. Using the above information, 
CIDSETUP creates two OS/2 2.x client 
boot diskettes. There is one exception, 
however; if your code server’s operating 
system is OS/2 2.1, then CIDSETUP cannot 
create OS/2 2.0 boot diskettes. 

Creating Product Images 

As product images are added to the serv¬ 
er, CIDSETUP creates a \CID directory 
structure. In general, each product has an 
image directory, a response file directory, 
and a log directory. For example, if you 
choose to install the Communications 


Server Setup 


Code Server Setup 



02 


Ul Server 


D 


Create Images Create Diskettes 


Print Registration Form Help 
Figure 1. Code Server Setup 


Product 

Command to Install 

Storage Location 

OS/2 2.0 

SEIMAGE 

\CID\IMG\0S2V20 

\CID\EXE\0S2V20 

\CID\DLL\0S2V20 

OS/2 2.0 

XCOPY 

\CID\CSD\0S2V20\WR6055 

ServicePak 1 


\CID\EXE\0S2V20 

\CID\DLL\OS2V20 

OS/2 2.0 

XCOPY 

\CID\CSD\0S2V20\XR6100 

ServicePak 2 


\CID\EXE\0S2V20 



\CID\DLL\0$2V20 

OS/2 2.1 

SEIMAGE 

\CID\IMG\0S2V21 

\CID\EXE\0S2V21 

\CID\DLL\0S2V21 

NTS/2 

LAPSDISK 

\CID\IMG\LAPS 

\CID\IMG\SRVIFS 

\CID\IMG\LCU 

\CID\SAMPLE 

\CID\APPLETS 

\SERVER 

Extended Services 

ESAIMAGE 

\CID\IMG\ES10 

DB2/2 Single User 

XCOPY 

\CID\IMG\DB22\DB2SU 

i * . . 

DB2/2 Client/server 

XCOPY 

\CID\IMG\DB22\DB2CS 

DB2/2 Client- 
Enabler 

XCOPY 

\CID\IMG\DB22\DB2CE 

Communications 

CMIMAGE 

\CID\IMG\CM10 

Manager/2 1.0 


. 

Communications 

Manager/2 1.01 

CMIMAGE 

\CID\IMG\CM101 

LAN Server 3.0 

LANINST 

1 \CID\IMG\LS30 

NetView DM/2 

Extended 

NVDMCOPY 

j \CID\IMG\IBMNV0M2 

NetView DM/2 Entry 

NVDMECPY 

j \CID\IMG\NVDMENTY 


Figure 2. Supported Products in CIDSETUP 
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Manager/2 (CM/2) 1.0 product images, 
CIDSETUP creates the directories shown 
in Figure 4. 

The CM I MAGE command places all of 
CM/2’s product files in \CID\IMG\CM10 
(see Figure 2). If any sample response files 
are provided with the product, they are 
copied to the \CID\RSP\productname 
directory. This directory structure is creat¬ 
ed when the CM/2 1.0 icon, shown in 
Figure 5, is pressed. 

Figure 2 shows that most products store 
their files in the directory 
\CID\IMG\productname, where pro- 
ductnameisa one- to eight-character 


name. For instance, productname 
CM 10 represents Communications 
Manager/2 1.0. 

Figure 2, however, also shows that there 
are some exceptions to this rule. OS/2 2.0, 
OS/2 2.0 ServicePaks, OS/2 2.1, 

DATABASE 2 OS/2 (DB2/2), and Network 
Transport Services/2 (NTS/2) have unique 
requirements that CIDSETUP handles for 
you. The next several paragraphs point 
out these exceptions. 

OS/2 2.x not only creates the image, 
response file, and log directories, 
but each version of OS/2 also 
creates \CID\EXE\0S2V2x and 


You can modify the following parameters with CIDSETUP: 


Server Name 
Group Name 
Path 

Log File Drive 
Response File Drive 
Command File Drive 
Adapter 

Maximum Number of Threads 
Maximum Number of Concurrent Installs 
Maximum Number of Open Files 
Alias Name 

Type of Share (either Per-Client or Single) for Alias 
Read/Write for Alias 
Server Path to Alias 

Figure 3. SRVIFS Server Configuration Keywords 


m^^g^lmages \CID\IMG\CM10 

Response File \CID\RSP\CM10 

Log File \CID\L0G\CM10 

Figure 4. \ CID Directory Structure for Communications Manager/2 1.0 


Sii Create Images 


Create Disk Images 

Source Drive a Images Installed 

Target Drive D on this target drive 


ServicePak 6100 NTS/2 LAPS 

kiH aa 

I AN Server .3.0 I AN Server 3.0 Servir.ePak 

C C CM% 

CM/2 1.0 CM/2 1.01 Extended Services 


CM/2 1.0 
CM/2 1.01 

DB2/2 Client Enabler 
DB2/2 -Cllent/Server 
DB2/2 Single User 
Extended Services 
IAN Server 3.0 
NTS/2 LAPS 


Figure 5. Create Disk Images 


\CID\DLL\0S2V2x. The 
\CID\EXE\0S2V2x directory stores 
all of the executable files required 
by the client machines during the 
installation process. Likewise, the 
\CID\DLL\0S2V2x directories store all 
of the .DLL files required by the client 
machines. Figure 6 lists the contents of 
each of these directories. 

ServicePaks are also exceptions to the 
rules. All Corrective Service Diskettes 
(CSDs) are stored in the \CID\CSD\pro- 
ductnameXcsdversion directory, where 
csdversion is the one- to eight-character 
representation of the CSD level. The 
response files and the log files are stored 
in \CID\RSP\CSD\productname 
\csdversion and \CID\L0G\CSD 
\productname\csdversion directories 
respectively. For example, the OS/2 2.0 
ServicePak XR06100 is stored in the 
\CID\CSD\0S2V20\XR6100 directory; its 
response files are located in 
\CID\RSP\CSD\0S2V20\XR6100; 
and its log files are located in 
\CID\LOG\CSD\OS2V20\XR6100. 

DB2/2 requires just a slight modification 
to the rules. Because DB2/2 comes in dif¬ 
ferent varieties, CIDSETUP creates a 
\CID\IMG\DB22 directory as the root 
directory. Then each version of DB2/2 is 
placed in a subdirectory under 
\CID\IMG\DB22. For instance, DB2/2 
single user images are stored in 
\CID\IMG\DB22\DB2SU. The response 
file and log file directories follow the 
same scheme. 

NTS/2 is the final product with exceptions 
to the rule. CIDSETUP creates a 
\CID\IMG\LAPS directory to store the 
NTS/2 images that are used to install 
LAPS on the client machine. CIDSETUP 
also creates \CID\IMG\SRVIFS and 
\CID\IMG\LCU directories to store the 
SRVIFS and LCU files that the client 
accesses throughout the installation pro¬ 
cess. In addition, CIDSETUP creates two 
directories for storing sample NTS/2 files 
and NTS/2 applets: \CID\SAMPLE and 
\CID\APPLETS. 

While the above exceptions may appear 
confusing-and they are-don’t worry; 
CIDSETUP handles them all. All you have 
to be concerned about is providing the 
product diskettes and selecting the right 
icon! 
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Building Client Boot Diskettes 

Using the OS/2 images stored on your 
code server, CIDSETUP can create your 
client boot diskettes. CIDSETUP fills in 
the A: default target drive with “A,” the 
default server name as defined in 
CIDSETUP during the SRVIFS code server 
installation, and a default adapter type of 
IBM token-ring. You can change any of 
these default values. In addition, 

CIDSETUP prompts you to furnish the 
client name and to select which version of 
OS/2 diskettes you wish to create. 

Figure 7 shows the CIDSETUP interface for 
creating client boot diskettes. 


\CID\EXE\0S2V20 \CID\DLL\0S2V20 


SEIMAGE.EXE 

SETB00T.EXE 

SEINST.EXE 

SEDISK.EXE 

XC0PY.EXE 

RSPINST.EXE 

SEMAINT.EXE 


UHPFS.DLL 

REX.MSG 

REXH.MSG 

REXX.DLL 

REXXAPI.DLL 

REXXINIT.DLL 

REXXTRY.CMD 

REXXUTIL.DLL 

RXQUEUE.EXE 

RXSUBCOM EXE 


\CID\EXE\0S2V21 

UNPACK2.EXE 

SEIMAGE.EXE 

XC0PY.EXE 

SETB00T.EXE 

SEMAINT.EXE 

SEINST.EXE 

SEDISK.EXE 

RSPINST.EXE 


\CID\DLL\0S2V21 

UHPFS.DLL 

REXX.DLL 

REXXAPI.DLL 

REXXUTIL.DLL 

REXH.MSG 

RXQUEUE.EXE 

RXSUBCOM.EXE 

REXXTRY.CMD 

REX.MSG 

REXXINIT DLL 


Figure 6. \ EXE and \ DLL Directory Contents 


Once you give CIDSETUP all of the 
required information, the utility executes 
SEDISK to create your two client boot 
diskettes. After SEDISK completes, 
THINLAPS, THINIFS, and CASINSTL are 
executed to store the LAN transport on 
your diskettes. 

Editing the LAN CID Utility 
Command File 

The default LAN CID Utility (LCU) com- 
mand file provided with CIDSETUP acts as 
a template file. You must edit it to suit 
your requirements. For instance, at a mini¬ 
mum, you must change the server name 
parameter in the THINIFS section. You 
must also make sure that you include only 
the products that you want to install. For 
more information about modifying the 
LCU command file, refer to the IBM 
Network Transport Services/2 Redirected 
Installation and Configuration Guide. 


rail Create Diskettes 


Build Client Boot Diskettes 

Target Drive 

1 


Enter Client Name 


MYCI lENTi 

Enter Server Name 


SRVNAME 

Select Adapter Name 


IBM Token-Ring Network t 


•jOS/2 V 2.1 QOS/2 V 2.0 


OK 



i Help I 


Figure 7. CIDSETUP Client Boot Diskettes Creation Screen 


Future Enhancements 

IBM programmers are working on three 
major enhancements to CIDSETUP in 
1994 . With these enhancements, you will 
be able to install a NetWare code server, a 
TCP/IP code server, and a NetView DM/2 
code server. In addition to the three 
major enhancments to CIDSETUP, new 
product images will be supported when 
they become CID-enahled. 

How to Obtain CIDSETUP and 
Support 

CIDSETUP is distributed via IBM’s OS/2 
Bulletin Board System (BBS) and the IBM 
PC Company Bulletin Board System. The 
name of the package is CIDSETUP. 


Support for CIDSETUP is provided on a 
best-effort basis via the OS2INST CFORUM 
on the OS/2 BBS. Phone support is not 
currently provided. 

For more information about CIDSETUP or 
any of the other products or programs 
available from IBM’s PSCC, call 
(800) 547-1283. 



Call us at 1-800-547-1283 


Tom Lambert is an 
associate marketing 
support representative 
in the IBM Personal 
Systems Competency 
Center in Roanoke, 
Texas. He is responsi¬ 
ble for developing 
CIDSETUP and 
LAD/2. He joined IBM 
in 1991 after earning a 
bachelor’s degree in 
business administra¬ 
tion from the University 
of North Texas at 
Denton. 


PERSONAL SYSTEMS • JANUARY/FEBRUARY 1994 


43 


























Managing Token-Ring Bridges 
with iBM’s LAN Network 
Manager 


This article offers a technical overview of token-ring management 
by bridges. It discusses the requirements for managing bridges, the 
functions and control supported by IBM’s bridges, and the manage¬ 
ment offered by IBM’s LAN Network Manager using this data flow. 


• Detecting and recovering a lost token 
or frame 

• Detecting and recovering multiple 
tokens 


A lthough an essential characteristic of a local area network (LAN) is shar¬ 
ing a common medium such as token-ring or Ethernet*, control of LAN 
traffic is distributed among the participating devices. Each station per¬ 
forms significant self-management and network monitoring functions; there¬ 
fore, in a LAN environment, the first level of network management is provid¬ 
ed by the LAN adapters in each station. 


• Controlling timing 

• Detecting and recovering a circulat¬ 
ing priority token or frame 

• Detecting and recovering multiple 
active monitors 


Sallie Matlack 
IBM Corporation 
Research Triangle Park, NC 


The token-passing ring protocol 
concepts are implemented in the 
adapters themselves and con¬ 
tribute to the availability, perfor¬ 
mance, and manageability of a 
token-ring LAN. Implementing 
IEEE* 802.5 standards supports 
this high level of management 
intelligence. Token-ring stations 
act as segment monitors (either 
active or standby) for functions 
such as: 



IBM’s token-ring adapter cards inherently provide greater control and man¬ 
agement at the Medium Access Control (MAC) level than is provided by a 
Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access pro¬ 
tocol adapter. (Ethernet, for example, uses the CSMA/CD access protocol.) 
Although various intelligent hubs in the CSMA/CD environment provide a 
level of management roughly 
equivalent to that provided by 
token-ring adapters, this level 
of management is not provided 
at the workstation level. 


Token-ring stations can also take actions 
to perform ring purging, neighbor iden¬ 
tification and notification, beaconing, 
and soft-error management. For more 
information about these token-ring 
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Figure 1. Internal Communication Structure of Bridge Management Agents 


management concepts, refer to the IBM 
red book titled Local Area Network 
Concepts afid Products (GG24-3178). 

The IBM token-ring network implementa¬ 
tion uses IEEE 802.2 logical link 
control-level information frames 
(1-frames). IBM designed additional con¬ 
trol frames for managing bridges, encap¬ 
sulating this information in the I-frames. 
These control frames are documented in 
the IBM Token-Ring Netivork 


Architecture Reference manual (SC30- 
3374). 

IEEE 802.5 is designed around the 
premise that MAC frames are single-seg¬ 
ment flows (“LAN-locked”). In fact, it is 
architecturally illegal to route MAC frames 
outside their local segment. For this rea¬ 
son, IBM introduced the management 
server concept that gathers, diagnoses, 
and forwards information about the local 
segment to a remote manager. 


A LAN Error Monitor (LEM) function col¬ 
lects and analyzes error information gener¬ 
ated at the LAN MAC protocol level for a 
given LAN segment. On an IBM token-ring 
LAN segment, this server function is called 
Ring Error Monitor (REM). 

IBM has designed other management 
servers that support the MAC frame han¬ 
dling. These other servers include the 
LAN Parameter Server (LPS or RPS on a 
token ring). Configuration Report Server 
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(CRS), LAN Bridge Server (LBS), and LAN 
Reporting Mechanism (LRM). Figure 1 dia¬ 
grams the internal communications struc¬ 
ture of these bridge management agents. 

IBM’s LAN Network Manager (LNM) sup¬ 
ports the server in receiving, processing, 
and reacting to the Logical Link Control 
(LLC) management flow of token-ring sta¬ 
tions on the segment local to the LNM 
workstation. If a LAN network manage¬ 
ment station is to manage segments out¬ 
side its local connection, it must “link” to 
a bridge that provides these server func¬ 
tions for the remote segments. 

In addition to containing management 
servers to support the functions described 
above, a bridge can also be intelligent 
enough to gather statistics about the traf¬ 
fic flow across the bridge. These statistics 
can be used by a network manager to 
monitor performance of the LAN. IBM’s 
LAN Network Manager can set or change 
the Performance Notification Interval (as 
supported by the bridge), which sets and 
controls the frequency for gathering this 
information. 

IBM Bridge Offerings 

IBM token-ring bridges act as agents for 
LAN Network Manager, offering the func¬ 
tions of LAN Reporting Mechanism, LAN 
Bridge Server, Ring Error Monitoring, 

Ring Parameter Server, and Configuration 
Report Server. Today, the specialized com¬ 
munications between IBM bridges and 
LAN Network Manager are supported in 
the IBM Token-Ring Network Bridge 
Program, the IBM 8209 LAN bridge for 
token-ring and Ethernet interconnect, and 
the Peer Communications Bridge option 
of the 3174 controller. In the near future, 
IBM intends to release other products con¬ 
taining this support. Recent announce¬ 
ments include the IBM 8250 Intelligent 
Hub with a bridge module containing sup¬ 
port similar to IBM’s token-ring bridge 
programs and the IBM DOS Local and 
Remote Token-Ring Bridge Programs. 

LAN Reporting Mechanism 

The LAN Reporting Mechanism handles 
the LLC Type 2 sessions between the man¬ 
ager (such as IBM’s LAN Network 
Manager) and the appropriate server func¬ 
tion (request or command) within the 
bridge. On the ring-segments side, man¬ 
agement requests or commands are trans¬ 
lated into the appropriate MAC frames for 


execution on one of the two attached ring 
segments. Responses provided by the 
appropriate server are directed to the 
LRM, which packages them into an LLC 
frame addressed to the originating man¬ 
ager station. 

A bridge can support management func¬ 
tions for segments on both sides of the 
bridge. IBM bridges currently support one 
“controlling” manager and up to three 
“observing” managers. (The “IBM LAN 
Network Manager” section later in this 
article explains these terms.) 

LAN Bridge Server 

The LAN Bridge Server (LBS) handles the 
following bridge processes: 

• Reading and validating bridge parame¬ 
ters from a configuration file during 
bridge initialization, and whenever a 
controlling manager modifies bridge 
parameters. IBM’s LAN Network 
Manager uses the concept of “control¬ 
ling” and “observing” managers. 

• Performing the bridge self-test through 
the bridge user interface when either 
the bridge initializes it or when an 
operator requests it. This test detects 
duplicate parallel paths and invalid net¬ 
work configurations caused by inconsis¬ 
tent ring numbering. 

• Maintaining a set of performance coun¬ 
ters for each adapter, including coun¬ 
ters for the number of frames discard¬ 
ed, not received, or not forwarded for 
any other reason, as well as for the 
number of broadcast and non-broadcast 
frames and bytes forwarded. LAN 
Bridge Server will also report accumu¬ 
lated values on request. 

• Accumulating path trace information 
for frames carrying a system path trace 
bit that is set to on in the routing infor¬ 
mation control field. 

Ring Error Monitor 

The bridge’s Ring Error Monitor (REM) 
server function compiles error statistics 
from received Sof t_Error_Report MAC 
frames, and selectively generates reports 
for the manager, depending on the soft 
error reporting mode-normal or inten¬ 
sive-set by the manager. 

The second major function provided by 
the REM server is beacon processing. This 
includes watching the timing of beacons. 


distinguishing between temporary and 
permanent beaconing states, and knowing 
when an adapter has been kicked off the 
ring. 

Ring Parameter Server 

The Ring Parameter Server (RPS) is the 
target for all Request Initial ization 
MAC frames sent by ring stations while 
attached to the ring segments. In response 
to the Request Initialization MAC 
frame, the RPS function makes the follow¬ 
ing parameters available to all ring 
stations: 

• Ring number 

• Ring Station Soft Error Report Timer 
value (default of 2 seconds) 

• Physical location (not currently 
implemented in all bridges) 

Configuration Report Server 

The Configuration Report Server (CRS) 
forwards configuration notifications to 
the manager(s). After receiving a MAC 
level configuration notification, it trans¬ 
mits the information via the LAN 
Reporting Mechanism to the manager(s). 
From the manager(s), CRS executes such 
commands as Query Adapter, Remove 
Adapter, and Set Station 
Parameters on a bridge-attached LAN 
segment. 

Bridge Configuration Support 

IBM’s token-ring bridge offerings support 
varying levels of bridge configuration con¬ 
trol settings. The following list describes 
the options supported by IBM’s LAN 
Network Manager: 

• Percent Frames Lost Threshold 

• Bridge Number 

• Automatic Bridge Link 

• Frame Forwarding Active 

• Single-Route Broadcast Mode 

• LAN Segment 

• Single-Route Broadcast 

• Hop Count 

• Largest Frame Size 

• LAN Segment Number(s) 

Some bridge types, specifically the IBM 
8209 , require unlinking and relinking the 
bridge before any bridge configuration 
changes take effect. 
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Commands 


Bridge 


Management 

Agents 



IBM Bridges Supported: 

• DOS TR Bridge Programs 

• 8209 TR/TR & TR/Ethernet 

• 3174 Peer Communications 

• 8250 TR Bridge Module 


(Connection-Oriented) 


Management Agents 

• Configuration Report Server (CRS) 

• Ring Error Monitor (REM) 

• Ring Parameter Server (RPS) 

• LAN Reporting Mechanism (LRM) 

• LAN Bridge Server (LBS) 


Figure 2. Bridge Management Agents in a LAN Network Manager Environment 


Performance Data 

The various traffic statistics reported by 
IBM bridges are also useful for analyzing 
potential traffic bottlenecks and helping 
network administrators reconfigure their 
LAN and applications to improve overall 
performance. Bridges can report this 
information at given performance inter¬ 
vals, storing the data in a network man¬ 
agement application for later reporting 
and analysis. IBM token-ring bridges 
report the following information: 

• Bridge Name 

• Percent Frames Lost Threshold 

• LAN Type 

• LAN Segment 

• Broadcast Frames/Bytes 

• Non-Broadcast Frames/Bytes 

• Inoperative Target LAN Segments 

• Adapter Congestion 

• Number of Frames Not Passed Due to 
Invalid Frame 

• Telecommunication Link Errors 


IBM’s LAN Network Manager 

IBM’s LAN Network Manager is the pre¬ 
mier product for managing the physical 
media in the IBM token-ring LAN environ¬ 
ment. In addition to taking advantage of 
the intelligence found in IBM’s token-ring 
cards, LAN Network Manager is supported 
by special bridge management code in 
various IBM and OEM hardware and soft¬ 
ware products. These bridges act as 
“agents” for the token-ring and Ethernet 
segments-collecting configuration, fault, 
and performance information. 
Supplemented by the information inter¬ 
change and remote-control capabilities 
provided by IBM’s 8230 Controlled Access 
Unit, LAN Network Manager has no peer 
in managing the physical layer’s token 
ring. 

IBM token-ring bridges have built-in serv¬ 
er components used for management, as 
discussed previously. These server compo¬ 
nents can use another component, the 
LAN Reporting Mechanism, to establish a 
reporting link with up to four IBM LAN 
Network Managers. Each reporting link is 
an IEEE 802.2 logical-link control Type 2 


(connection-oriented) link, dedicated to 
transporting network management infor¬ 
mation in either direction. Figure 2 dia¬ 
grams the network management flow 
between LAN Network Manager and a 
bridged token-ring segment. 


Although the IBM Token-Ring Network 
Architecture Reference manual docu¬ 
ments some of the information flow 
between IBM’s LAN Network Manager and 
the supporting bridge programs, the inter¬ 
face is basically proprietary. OEM vendors 
have implemented some of the bridge 
server functions as described above, but 
some installations have reported LNM’s 
failure to link to or manage these bridges. 
IBM does not support these environments; 
it is the responsibility of tbe OEM vendors 
to test and verify their products and 
releases. 


Future directions for IBM indicate that 
this bridge interface will be supported by 
LAN Network Manager under the newly 
accepted IEEE 802.IB and 802.1k stan¬ 
dards for Common Management 
Information Protocol over LLC Type 1 
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Figure 3. Remote Bridge Concept 

(CMOL). This standardized Heterogeneous 
LAN Management (HLM) protocol enables 
CMIP Management Information Bases 
(MIBs) to be shipped over CMOL to 
describe the bridge information gathered, 
and allows LAN Network Manager to 
change control variables within the 
bridges. OEM vendors will be able to 
implement this interface. 

A single LAN Network Manager can link to 
255 two-port bridges, thereby managing 
up to 256 token-ring segments. This prod¬ 
uct can automatically attempt to re link 
lost bridges, to provide notification when 
bridges become linked, and to issue mes¬ 
sages when bridges have become decon- 
gested and are able to pass traffic effi¬ 
ciently. Of course, all of these functions 
must be supported by the bridge. 

A LAN Network Manager supports two 
configurations: controlling mode or 
observing mode. In a network there can 
be multiple controlling LAN Network 
Managers, but each bridge can only be 
linked to a single manager running in 
controlling mode. Up to three managers 
can be linked to that same bridge in 
observing mode. The main functional dif¬ 
ference between the two configuration 
types is that a LAN Network Manager run¬ 
ning in observing mode is restricted to 
query and status operations and cannot 
influence or alter the function of the 
remote LAN segments. 

All of the functions and capabilities dis¬ 
cussed previously and offered by IBM’s 
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token-ring bridges are supported by LAN 
Network Manager. The graphical network 
picture displayed by LNM can optionally 
identify bridges within the domain by a 
user-selected unique icon. By navigating 
through the windows, the network admin¬ 
istrator can view bridge profiles, perfor¬ 
mance information and error reports, and 
can change bridge configurations. 

Database tables are maintained for bridge 
performance statistics, and all bridge 
information is (optionally) available to a 
host-connected mainframe running IBM’s 
NetView. The IBM NetView Performance 
Monitor is another product that accesses 
bridge performance statistics (through the 
NetView/LAN Network Manager interface), 
generating reports and graphs to assist in 
analyzing this data. 

Managing Remote Bridges 

A remote bridge, also called a split 
bridge, interconnects LAN segments using 
a telecommunication link for transmitting 
frames between bridge ports. Physically, a 
remote bridge consists of two halves on 
each side of the communications link. 
Figure 3 shows the physical configuration 
of the remote bridge concept. 

In a normal or local bridge, regular frame 
forwarding is done from one LAN adapter 
to the other. In a remote bridge, however, 
a frame is copied in one station from the 
LAN adapter to the communications 
adapter, adding source routing informa¬ 
tion as required. This communications 
adapter sends the frame across the com¬ 
munications link to the peer communica¬ 
tions adapter in the other half of the 


bridge where the LLC frame is copied to 
the second LAN adapter and transmitted 
on its LAN segment. Part of this transfer’s 
controlling process is routing the frames 
designated for the remote ring; not all 
frames are copied. 

Functionally, a remote bridge provides 
logical-link control level end-to-end con¬ 
nectivity between LAN stations on either 
side of the bridge, supporting any 
higher-level protocol carried over the LLC 
link. IBM supports remote bridges in the 
IBM Token-Ring Network Bridge Program 
and the new DOS Remote Token-Ring 
Network Bridge Program. 

These bridges not only support manage¬ 
ment identical to that offered in the local 
bridging environment, but also report 
error conditions on the communications 
link between the two pieces of the bridge. 

Managing Token Rings 
Through the IBM 6611 

Today IBM offers a Program Temporary 
Fix (PTF - UR37051) for the IBM 
Token-Ring Network Bridge Program 
Version 2.2 to provide bridge-server func¬ 
tions for a segment connected to LAN 
Network Manager through the IBM 6611 
Multi-Protocol Router. The supported con¬ 
figuration requires attaching the 6611 to 
the local segment of the LAN Network 
Manager workstation and attaching a ded¬ 
icated PC workstation acting as the sec¬ 
ond half of a remote bridge to the 6611. 
This remote workstation would have the 
token-ring bridge program as well as the 
PTF installed. 














LAN Network Manager links to the far 
adapter instead of to the 6611 side of the 
bridge and manages the bridged segment. 
This management is for the token-ring 
bridge side only, not for the 6611-to- 
bridge connection. MAC frames support¬ 
ing management for the remote segment 
must flow successfully through the remote 
segment and back to the bridge program 
for reporting to LAN Network Manager. 

This implementation presents two limita¬ 
tions when compared to the standard 
remote or split bridge management capa¬ 
bilities: 

• A beaconing state on the far 

ring cannot be specifically identified. 

• A loss of the TP link connecting the 
bridge and the 6611 cannot be 
determined. 

Basically, if a hard error disconnects the 
remote segment, the only notification that 
LAN Network Manager receives in this 
configuration is the loss of the link to the 
remote bridge. 

Other than the limitations just stated, this 
special support provides a rich set of man¬ 
agement capabilities, including: 

• Full Configuration Reporting and Ring 
Parameter Services (RPS) 

• All token-ring soft errors and temporary 
beacons reported to LNM through the 
Ring Error Monitoring server 
function 

• Performance counters for the remote 
ring sent to LNM and made available for 
viewing on the bridge performance 
screen of LNM 


• “Bridge performance threshold exceeded” 
alerts sent to LNM (These often work as 
early warnings that you may lose the 
LNM link.) 

• LNM used to configure both bridge per¬ 
formance thresholds and bridge perfor¬ 
mance notification intervals (LNM can¬ 
not be used to reset adapters and 
ports.) 

• Support of 8230s, 822()s, and trace 
and performance tools on a remote 
segment. 

This remote bridge management is sup¬ 
ported through IBM’s 6611 Multi-Protocol 
Router, which can pass LLC Type 2 bridge 
management frames through its bridging 
interface. 

Future Directions 

Although the purpose of this article is to 
explain the current bridge management 
support offered by IBM’s LAN Network 
Manager and IBM’s token-ring bridge 
products, the following list denotes some 
of the evolving areas of change: 

• LNM will offer an “open” protocol for 
bridge management based on CMOL 
(HLM). 

• The 6611 will add native bridge-server 
functions, removing the need for the 
separate token-ring bridge program run¬ 
ning on a PS/2. 

• LNM will manage multi-port bridges, rec¬ 
ognizing protocols other than token-ring 
on remote segments. 

• A new LAN media management applica¬ 
tion, AIX* LAN Network Manager/6000, 
will run on IBM’s NetView/6000*, offer¬ 
ing the interconnect of SNMP (simple 


network management protocol)-man- 
aged bridges with the LAN subnets with¬ 
in the typical LAN Network Manager 
domain. 
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Correction 

Figure 1 and Figure 4 were inadvertant¬ 
ly transposed in the “Advanced 
Client/server Computing Using the 
IBM ThinkPad” article in the 
November/December 1993 issue of 
Personal Systefns. Please note that 
Figure 1, Personal Application 
System/2 should reflect the screen cap¬ 
ture shown in Figure 4. Figure 4, Host 
and LAN Applications on a ThinkPad 
Client, should reflect the screen cap¬ 
ture shown in Figure 1. 


1 




PERSONAL SYSTEMS • JANUARY/FEBRUARY 1994 












IBM DCE for OS/2 Multiuser 
Application Performance 


This article responds to the question, ''How well does Distributed 
Computing Environment (DCE) for OS/2 perform?” 

We in the IBM Personal Systems Programming Center in Austin, Texas, 
have developed three benchmarks to help determine DCE's perfor¬ 
mance, and we present the results in this article. We discuss, at the 
application level, the performance characteristics and resource require¬ 
ments of multiuser applications running in DCE for OS/2. We describe 
our three workgroup environment benchmarks, and we give their base¬ 
line performance results and resource requirements, using measure¬ 
ments chosen in response to questions we received. We mention several 
variables that affect performance, and we discuss selected DCE APIs in 
the appropriate contexts. This information may help you make deci¬ 
sions while designing your DCE application. 


Remote Procedure Call 
Data-Transfer Benchmark 

This benchmark demonstrates DCE perfor¬ 
mance in a CPU-intensive environment. It 
is based on an existing Remote Procedure 
Call (RPC) sample program. The client 
sends a random-sized data packet, from 
1 to 8,192 bytes, to the server in a vari¬ 
able-length array. The server returns an 
array containing one byte. 

The RPC data transfers are authenticated 
by DCE Security; our baseline is call-level 
authentication. Information about the 
packet, packet integrity, and packet priva¬ 
cy levels are also included in this article. 


Multiuser 

Benchmarks 

Benetta Perry and Using this knowl 

Bob Russell edge base, we 

IBM Corporation devised three 

Austin, Texas multiuser hench- 

marks as our tools 
for evaluating 
DCE performance 
and system resource require¬ 
ments. Following are descrip¬ 
tions of three workgroup envi¬ 
ronment benchmarks conduct¬ 
ed in our multiuser, homoge¬ 
neous Workgroup Environment 
Lab. 



T he LAN Systems Performance Workgroup Environment team provides sup¬ 
port and consultation for Distributed Systems Services (DSS). Our team 
consults with vendors and customers about designing and tuning the new 
applications they are developing. From consulting with customers who use IBM 
OS/2 Extended Edition 1 .x and 
IBM OS/2 Extended Services* 

1.0, and from our experience 
with DCE beta customers, we 
have amassed a substantial 
base of knowledge about 
applications. 


Point-of‘Sale DCE Benchmark 

Point-of-Sale (POS) is a composite of 
highly visible activities gleaned from our 
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D = Primary DCE Cell Serviees 
La = LAN Server 3.0 Advanced 
Le = LAN Server 3.0 Entry 
A= POS Application Server 
DB = DBM Server 


Optional 

Connections 


Figure 1. Lab Topology 


application consultations with IBM 
customers. 

The POS scenario involves a retail show¬ 
room or parts store with terminals 
throughout the store. Either store person¬ 
nel or customers can place orders, which 
are immediately filled from back-room 
stock. The POS scenario has the following 
chronology: 

1. The POS application user randomly 
chooses a 16 KB bit-image of a catalog 
page from one of five catalog 
repositories. 

2. The POS application user randomly 
selects one to four items from the cata¬ 
log page. A 168-byte price and inven¬ 
tory record is returned for each item. 

3. Using the customer’s area code and 
phone number, the program returns a 
512 -byte customer information record. 

4. When the order is complete, the POS 
DCE application sends all information 
about the customer, items, and pay¬ 
ment method to the back-room reposi¬ 
tory so that a parts puller can prepare 
an invoice and fill the order. 

According to the benchmark data, the 
average customer sale consists of 5.5 
authenticated RPC transactions. The aver¬ 
age POS data size is nominally 3,250 
bytes. The POS data is stored in eight 
OS/2 flat-file repositories and is accessed 
by IBM C Set/2* library calls. 


Our throughput calculations include the 
times that the client takes to display the 
answer sets for these POS transactions 
(except bit images). 

Database Manager Online Transaction 
Processing Benchmark 

An IBM OS/2 Extended Services 1.0 Data¬ 
base Manager (DBM) Online Transaction 
Processing (OLTP) benchmark compares 
the transaction-oriented packaging provid¬ 
ed by DCE RPC with the native DBM 
Application Remote Interface (DARI). RPC 
and DARI are product-specific interfaces 
that package one operation or several 
associated operations as a single unit of 
work in a single remote call. Here, we 
define a unit of work as a sequence of 
statements and operations that can be 
performed without user intervention. For 
example, some industry-standard database 
benchmarks consist of four or five 
Structured Query Language (SQL) state¬ 
ments and several intervening C state¬ 
ments packaged into a single remote pro¬ 
cedure with a single remote invocation 
across the wire. 

In a single call to a server, DCE RPC and 
DBM DARI’S equivalent packaging and 
transport services support the scope of a 
transaction. 

Simulated Workload 
Descriptions 

This report’s results are based on simulat¬ 
ed workloads. Each PS/2 client can simu¬ 
late the system load of one or many physi¬ 
cal workstations. We varied the number of 


physical workstations and the arrival 
rates appropriately for each benchmark. 

We used the following workload assump¬ 
tions to determine the number of simulat¬ 
ed clients: 

• One terminal can submit one POS cus¬ 
tomer sale (5.5 transactions) in one 
minute. 

• One terminal can submit one DBM OLTP 
transaction every ten seconds. 

• One terminal can submit one RPC data 
transfer every ten seconds. 

Workgroup Environment 
Performance Lab Topology 

Although the topology of the Workgroup 
Environment Lab allows a variety of 
homogeneous connectivities and worksta¬ 
tion roles (as indicated in Figure 1), the 
scope of this article is limited to the 
OS/2-to-OS/2 connectivities. 

Our definitions of server and client 
include all the products and services indi¬ 
cated in Figure I, installed and started. 

Some graphs in this article may have a 
zigzag pattern that appears ill-behaved. 
This sawtooth appearance is due to the 
different processor characteristics of the 
386SX and 386SLC* clients interspersed 
in the test cells. These results are consis¬ 
tently reproduceable. 
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Figure 2. Point-of-Sale Baseline 

TPS 



Figure 3. Data-Transfer Baseline 
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Figure 4. Response-Time Distribution 


The DCE Paradigm Shift 

Why is the industry reinventing the local 
area network (LAN) when we already 
have the technology to bridge and splice 
LANs, wide area networks (WANs), and 
gateways into a global network? DCE sup¬ 
plies the pieces missing from this global 
web of copper wire and fiber-optic cable: 
location/platform transparency and man¬ 
ageable administration. 

At the IBM Personal Systems Program¬ 
ming Center, we have hundreds of net¬ 
work users connected to dozens of net¬ 
work domains. We put new applications 
on the network every week. Heretofore 
our challenge has been twofold: 

Challenge 1: We must know where the 
application is, so we can find it. (A famil¬ 
iar analogy is that we need to know how 
to spell a word before we can look it up 
in a dictionary.) 

Eventually we would discover-on scraps 
of paper taped to the wall-a new network 
path to add to our already long list of 
NET USE/MOUNT instructions. Another 
obstacle was security; more often than 
not, the server didn’t know who we were. 
Thus, our second challenge: 

Challenge 2: We must have identities in 
the remote domain to use it. 

A few phone calls to the appropriate LAN 
administrators, an exchange of notes, and 
we were ready to begin. 

DCE is an industry-wide effort to provide 
transparent interoperability for the com¬ 
puting environment. The Open Software 
Foundation* (OSF)* DCE architecture is 
currently being implemented on many 
major hardware and software platforms. 
No longer are we limited to OS/2-to-OS/2 
or IBM-to-IBM; distributed computing is a 
completely new paradigm. 

Now, some of us are DCE converts. We 
don’t need to know if the DCE application 
server is located in Austin or Timbuktu; 
DCE Directory Services knows where it is. 
We don’t need to know its logical path or 
to NET USE/MOUNT a network drive to 
access it. With a single DCE login to our 
local DCE cell, DCE Security and Directory 
Services will handle our connection with, 
and authentication of, remote DCE appli¬ 
cations. When all or part of a DCE server 
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application is moved to another part of 
the network, or onto a different platform, 
we don’t need to know, nor do we care. 

Location transparency, once a buzzword, 
is now a reality. We routinely move all or 
part of the POS DCE application between 
our OS/2 and AIX platforms during per¬ 
formance testing. Balancing the POS load 
between OS/2 and AIX, or providing mul¬ 
tiple application servers on both plat¬ 
forms, is completely transparent to the 
client. The client is totally unaware of 
which server or platform is processing 
any given transaction. 

Performance Results 

This section presents performance results 
of DCE for OS/2 in the areas of Point-of- 
Sale (POS) and Online Transaction 
Processing (OLTP). 

Baseline Tests 

We ran baseline tests with a variety of 
simulated workloads to assure that the 
POS application server was sufficiently 
busy to make the results interesting. 
Considering the results of the baseline 
tests, we elected to show only the work¬ 
load ranges in Figures 2 and 3. 

In Figure 2, POS throughput begins to 
flatten at about 23 transactions per sec¬ 
ond (TPS). An increased workload does 
not drive any more work through the 
server. The resource boundary that POS 
encounters is hard-disk access. 

Figure 3 illustrates the data-transfer 
benchmark throughput. The same flatten¬ 
ing is observed at about 67 transfers per 
second. Additional workload does not 
drive any more work through the system. 

The data presented in this article may he 
for either Cell E or Cell J. The main differ¬ 
ence in how the two cells behave is the 
server’s file system. The server for Cell E 
uses the HPFS386 file system, which is 
tuned for file-sharing. The server for 
Cell J uses the standard HPFS file system, 
which is tuned to local input/output (I/O). 
Because the baseline measurements may 
vary slightly, the graphs refer to the 
appropriate baseline or control group. 

Distribution of Response Times 

Each client records a histogram of 
response-time distributions during POS 
tests, then combines the histograms into a 
single aggregate. The histogram granularity 



Simulated Number of Clients 
Figure 5. POS Response-Time Proration 
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Figure 6. OLTP Response-Time Proration 



(*) The OS/2 DCE announcement recommended 14 MB of RAM for acceptable steady-state performance. We are revis¬ 
ing the client's minimum RAM requirement downward from 14 MB to 10 MB. Extensive additional testing has showti 
that 10 MB sustains acceptable steady-state performance with minimum swapping. A DCE cliettt can be configured 
and run uith as little as 8 MB of RAM; however, at 8 MB, the performance of many ordinary tasks would be 
unacceplable. 

Figure 7. Minimum Recommended RAM for DCE Servers and Clients 
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Figure 8. Client RAM Requirements 
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Figure 9. Server RAM Requirements 


nearly 100% utilized. The middle area is 
attributed to the RPC call, and remains 
somewhat constant at all load levels. 

Figure 6 shows the proration of response 
time for the DBM OLTP benchmark using 
DCE RPC as the transport package. 

Figures 5 and 6 suggest that most of the 
elapsed time is in either the client or 
server application, and very little time is 
required by the DCE services. This is gen¬ 
erally true for many applications. 

Resource Requirements 

Most questions we get about DCE concern 
memory (RAM) and hard-disk (DASD) 
requirements. In Figure 7, we spell out the 
minimum requirements for RAM on a DCE 
server and on a DCE client, and we give 
our recommended amounts of RAM. 

We used IBM System Performance 
Monitor/2 (SPM/2) THESEUS2 Memory 
Analysis Tool to collect the RAM usage 
data given in Figures 8 and 9- The indicat¬ 
ed minimum values have been verified in 
physical RAM configurations. We can char¬ 
acterize the system performance at the 
minimum configurations thus: 

• During initial startup, performance 
degrades somewhat due to swapping 
activity. 

• After startup, the steady-state applica¬ 
tion performance is satisfactory with 
some swapping activity. 



Figure 10. DCS DASD Requirements 

in Figure 4 is 0.1 seconds. All transactions 
were completed in less than 1.2 seconds, 
with 90% being completed in less than 
0.6 seconds. 

POS Response-Time Proration 

Figure 5 shows the proration of the 
response time charged to the POS client 


application, the RPC remote call, and the 
POS server application. The time spent in 
the POS client is the greatest portion, and 
remains somewhat flat at all user levels. 
The POS server application is the 
second-largest portion, and is the most 
varied due to queueing of disk I/O 
requests. Under full client load, the disk is 


The POS application has a relatively small 
RAM working set. We recommend using 
the minimum values as a base, with the 
target application’s RAM requirements 
added to this base when estimating the 
total RAM required. 

We set the following parameters for mea¬ 
surements affecting the RAM working set: 
64 KB in the client; I MB in the server 
HPFS cache; and DISKCACHE in 
CONFIG.SYS. The IBM AnyNet/2* Multi- 
Protocol Transport Services (MPTS) 

MBUFS were set at 512/64 in the client 
and 640/120 in the server. (See the sec¬ 
tion on MPTS under Performance 
Sensitivity Studies for more information 
about tuning MBUFS.) 

Figure 10 lists the DASD requirements, 
including the recommended minimum, 
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for each system component. Figure 10 rep¬ 
resents a full installation of OS/2; the 
DASD required for OS/2 can be reduced to 
less than 40 MB by choosing the mini¬ 
mum OS/2 installation options. 

Performance Sensitivity 
Studies 

In this section, we discuss what happens 
to DCE performance by using different 
levels of authentication and by optimizing 
the number and sizes of send/receive 
buffers. 

RPC Authentication Levels 

DCE RPC provides six levels of authentica¬ 
tion and transaction security. Assuming 
that most applications require some level 
of security, we present only the four high¬ 
est levels-call authentication, packet, 
packet integrity, and packet privacy. The 
performance of the two lower levels, none 
and connection, is equivalent to the per¬ 
formance of the call level. 

Call authentication validates the client’s 
security credentials each time an RPC 
request is received by the application 
server. Subsequent data packets associated 
with the current call are not reauthenti¬ 
cated. 

Packet authenticates each data packet 
sent and received. 

Packet integrity authenticates each data 
packet and verifies the packet’s content 
with a check sum. 

Packet privacy uses the client’s key to 
encrypt each packet. This, therefore, is the 
slowest performer. 

Figure 11 shows the throughput for the 
POS application at the four authentication 
levels. Very little difference is noted 
between call and packet because the aver¬ 
age send/receive for POS is about 3,250 
bytes and is often a single packet. 

Since the DCE RPC proration of time for 
POS is only a small part of the total trans¬ 
action time, the throughput cost of 
authentication is not as dramatic as it 
would be in a data-transfer-intensive 
application. 


TPS 



Simulated Number of Clients 
Figure 11. Point-of-Sale Authentication Levels 
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Figure 12. RPC Data Transfer Authentication Levels 
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The cost of the higher authentication lev- pjgufg 13 Mpjs mbUFS Optimization 
els is more noticeable in the data-transfer 
benchmark in Figure 12. The DCE RPC 
proration of the response time is about 
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Figure 14. Minimum Configurations for MBUFS Parameters 
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Figure 15. RPC Data Transfer, TCP Versus UDP 
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Figure 16. Database OLTP, TCP Versus UDP 


90%. The system throughput overhead of 
packet privacy is 60% greater than for the 
POS application in Figure 11. 

Multi-Protocol Transport Services 

MPTS provides the TCP/IP, Sockets, and 
NetBIOS services for DCE. MPTS MBUFS is 
one of the more performance-sensitive 
parameters. 

CNTRL.EXE allocates a pool of send/ 
receive buffers during initialization. There 


are two sizes of buffers: the large MBUFS 
(clusters) are 4 KB each, and the small 
MBUFS are 256 bytes each. MPTS MBUFS 
are in fixed, non swappable memory. The 
default number of large MBUFS is 144, 
and the default number of small MBUFS is 
1024. 

Figure 13 shows that reducing the number 
of MBUFS can speed up performance by 
making more memory available to the sys¬ 
tem. Having fewer fixed-memory pages 


enables OS/2 memory management to 
function more effectively. 

We suggest the MBUFS parameters shown 
in Figure 14 as the minimum configura¬ 
tions. To monitor MBUFS usage, MPTS pro¬ 
vides a tool: just enter MPTSTAT -M on 
the command line. MPTSTAl reports the 
current usage and indicates whether any 
buffers have been dynamically allocated. 
Initial MBUFS values are parameters for 
C:\MPTN\BIN\CNTRL.EXE and are speci¬ 
fied in C:\MPTN\BIN\MPTSTART.CMD. 

Using these minimum settings, rather 
than the defaults, reduces the amount of 
fixed memory for MBUFS from between 
182 KB to 448 KB. 

The optimum values for the application 
server vary with individual application 
design. Because the POS application serv¬ 
er transfers several 16 KB packets, we had 
to increase the large MBUFS value to 120 
to avoid dynamic allocations. 

Cautions: 

• Avoid under-configuring. Values lower 
than these recommendations can cause 
DCE to hang during initialization. MPTS 
will not dynamically allocate MBUFS 
while DCE daemons are initializing. 
Configuring too few buffers can also 
cause MPTS to dynamically allocate 
more MBUFS at run time. Dynamic allo¬ 
cation carries a moderate performance 
penalty. 

• Configure a DCE server with 16 MB of 
RAM with fewer MBUFS than the 
defaults; otherwise, the server may 
hang during DCE initialization. Too 
many non-movable memory pages can 
interfere with OS/2 memory manage¬ 
ment in a 16 MB server. Too much disk 
cache can also create memory-manage¬ 
ment problems; we recommend no more 
than 640 KB total disk cache for this 
configuration. 

MPTS Protocols 

DCE optionally uses two TCP/IP protocols: 
transmission control protocol (TCP) and 
user datagram protocol (UDP). Since TCP 
delivers a higher level of verification, it 
takes longer to respond. TCP is slightly 
faster than UDP when the packet size is 
less than 2 KB. 

The data-transfer benchmark sends ran¬ 
dom-sized packets of between 1 and 8,192 
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bytes; the average transfer is about 4 KB. 
Figure 15 shows UDP to be the faster 
performer. 

Figure 16 compares the DBM OLTP bench¬ 
mark using DCE RPC with UDP and TCP, 
versus using the native DBM DARI on 
NetBIOS. The packet sizes for the OLTP 
benchmark are 16 bytes in and less than 
100 bytes out: therefore, in this applica¬ 
tion with small packet sizes, RPC using 
TCP performs noticeably better than UDP 
or DARI on NetBIOS. 

Name-Service Binding Import 

In our discussions with IBM DCE cus¬ 
tomers, we have become aware of the per¬ 
formance concerns for making frequent 
inquiries to DCE Cell Directory Services 
(CDS) to obtain a binding handle to a 
server application. Generally, the cus¬ 
tomers indicate that a CDS Binding 
Import could be part of every call to an 
application server. 

Figure 17 illustrates the cost of the 
RPC_NS_BINDING_IMPORT_NEXT call for 
one to 24 clients concurrently, after forc¬ 
ing a refresh of the client’s local CDS 
cache. The graph’s sawtooth appearance 
reflects the intermixed 386SX and 386SLC 
client processors. 

The POS benchmark can also be run with 
a cached binding import call before every 
customer sale. Figure 18 compares the 
throughput of the POS benchmark, with 
and without binding import and rebind¬ 
ing, before each customer sale (every 5.5 
transactions). 

Most of the other APIs used by these 
benchmarks completed in less than the 
OS/2 timer resolution of 32 milliseconds 
and have not been discussed. 

Client and Server Hardware 

The Austin Workgroup Environment Lab is 
equipped with PS/2 Model 95 servers 
(486, 33 MHz) and PS/2 Model 57 clients 
(386, 20 MHz). In many cases we found 
that most of the CPU cycles were occur¬ 
ring on the client for the DCE services. 
Figures 19 and 20 illustrate the response 
times of DCE LOG IN and 
RPC_NS_BIND1NG_1MP0RT_NEXT as the 
client and server hardware changes. The 
binding import forces a CDS cache 
refresh. 


Sec. 



Figure 17. Binding Import with Flush 
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Figure 18. Binding Import, None Versus Many 
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Figure 19. Hardware Sensitivity > DCELOGIN 
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Figure 20. Hardware Sensitivity - Binding Import 
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Figure 21. Single Client and Server Combinations 


Figure 21 lists the single client and server 
combinations whose performances are 
reported in Figures 19 and 20. 

The PS/2 Model 80 server performs quite 
well as a DCE server; however, we have 
not evaluated a 386-based server in a cell 
with more than 26 physical clients. The 
16 MB real-memory limitation of the 386 
requires that the total disk cache not 
exceed 640 KB and that MPTS MBUFS be 
configured at the minimum value of 
640/64. (Refer to the MPTS tuning section 
on page 56 for more information.) 

Clearly, the DCE client processor has a 
greater effect on the performance of these 
DCE services than the DCE server 
processor. 

PRIORITY.DISKJO Keyword in 
CONFIG.SYS 

Generally, OS/2 servers should have 
PRI0RITY_DISK_I0=N0 in their 
CONFIG.SYS files. The keyword 
PRI0RITY_DISK_I0 selects one of two 
disk I/O queueing algorithms. Setting this 
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keyword to YES invokes a multilevel pri¬ 
ority-oriented queue that can aggressively 
favor the foreground OS/2 session to the 
exclusion of other processes. Setting this 
keyword to NO, however, invokes a 
modified first-in-first-out (FIFO) queue 
that is less likely to starve background 
processes. For this reason, we recommend 
setting the PRI0RITY_DISK_I0 keyword 
to NO in DCE cell servers and DCE 
application servers. 

Summary 

• The queueing characteristics and 
response-time distributions of these 
three DCE applications in this multi¬ 
user environment are well-behaved. 

• The actual DCE proration of the elapsed 
time represents only a small part of the 
total for the applications tested. In a 
robust application, the proration of DCE 
time will be even smaller; therefore, the 
cost of RPC authentication should be 
less of a factor than in these tests, 
which were designed to stress the 
system. 


• Frequent calls to CDS for binding infor¬ 
mation from the client’s local cache are 
relatively inexpensive. Under maximum 
load, the client’s response time 
increased by 26%, while the server’s 
throughput degraded less than 7%. 

• The performance of RPC as a Database 
Manager transport compares favorably 
with the DBM DARI using NetBIOS. 
Integration of DBM into a DCE applica¬ 
tion should provide equal or better 
performance. 

• The speed of the client workstation 
hardware is a major factor in the 
end-user response time of DCE functions. 

• Several other DCE APIs were measured 
in the multiuser application tests. Most 
of these completed faster than the OS/2 
timer resolution of 32 milliseconds, so 
they were considered instantaneous. 
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Performance of Key Functions 
in DCE for OS/2 


This article is intended to help users efficiently configure and use IBM 
Distributed Computing Environment (DCE) for OS/2, It describes some 
basic performance characteristics of DCE for OS/2, It gives insights into 
the performance of different core components-in particular, Remote 
Procedure Call, Cell Directory Services, and Security Services—through 
various benchmarks and what-if scenarios. The article focuses on a set 
of the most important basic functions of DCE and gives some tips and 
helpful hints for performance improvements. 


• Cell Directory Services (CDS), which 
defines a naming model that allows 
users to identify resources by name 
without knowing their location 

• Security Services, which encrypts and 
authenticates client/server transactions 
to ensure their privacy and 
authenticity 


I BM Distributed Computing 
Environment (DCE) for OS/2 
is a fundamental building 
block for distributed comput¬ 
ing in an open systems envi¬ 
ronment. DCE provides ser¬ 
vices and 
tools that 
support the 
creation, 
use, and 
mainte¬ 
nance of 
distributed 
applications 
in the PC 
local area 
network 

(LAN) environment. The current 
implementation of IBM DCE for 
OS/2 is based on the Open 
Software Foundation (OSF) 

DCE 1.0.2. 


Cindy Corn, 

Tim Li, 

Ray Pekowski, and 
Bob Santeford 
IBM Corporation 
Austin, Texas 


This article addresses some 
performance characteristics of 
key basic functions in various 
core components of DCE: 

• Remote Procedure Call 
(RPC), which extends the 
typical procedure call model 
by supporting direct calls to 
procedures on remote 
systems 
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• Threads, which creates, manages, and 
synchronizes multiple threads of con¬ 
trol within a single process 

• Distributed Time Services (DTS), which 
synchronizes time on the computers 
participating in a distributed comput¬ 
ing environment 

For each of these components, this article 
first provides a simple tutorial, then gives 
performance information, and finally 
offers tips or helpful hints. 

System Configuration 

The hardware configuration used for this 
article is: 


Level of Security 

Function 

Connect 

Perform protection only when the client establishes a 
relationship with the server. 

Call 

- 

Perform protection only at the beginning of each Remote 
Procedure Call when the server receives the request. 

Packet 

Ensure that all data received came from the expected 
client or server. 

Packet integrity 

Ensure and verify that none of the data transferred 
between client and server has been modified. 

Packet privacy 

Perform protection as specified by all of the previous 
levels and encrypt each Remote Procedure Call argument 
value. 


• DCE Server: IBM PS/2 Model 95 (33 
MHz 486) with 1 6 MB of memory and a 
320 MB hard disk 

• DCE Client: IBM PS/2 Model 80 (25 Mhz 
386) with 16 MB of memory and a 320 
MB hard disk 

Server and client are connected by a l6/4 
token-ring adapter set at l6 Mbps. 

The software configuration used is IBM 
OS/2 2.1 plus the IBM Distributed 
Computing Environment Software 
Developer’s Kit for OS/2, Version 1.0. 

Remote Procedure Call 

The distributed communications model 
used by DCE is the procedure call. In this 
model, the client makes what looks like a 
procedure call. The procedure call is 
translated and communicated to a server 
routine, making the server routine believe 
it has been called locally. When the server 
returns, the results are communicated 
back to the client. 

The DCE component that implements this 
model is the Remote Procedure Call. All 
other components of DCE use RPC for 
their communication needs; therefore, 

RPC plays an important role in DCE 
performance. 

The client and server programs usually 
reside on two separate machines with 
possibly differing architectures. RPC run¬ 
time handles marshalling (copying input 
and output parameters to communication 
buffers), manages the communications 
link, and translates any architectural dif¬ 
ferences (such as byte reversal) between 
the client and server machines. 


Figure 1. RPC Security Levels 



Figure 2. RPC (UDP Versus TCP) 



Figure 3. RPC (UDP Versus TCP) 


PERSONAL SYSTEMS • JANUARY/FEBRUARY 1994 

























OS/2 DCE RPC operates over the transmis¬ 
sion control protocol/internet protocol 
(TCP/IP) communications service and sup¬ 
ports both of its underlying transports: 
transmission control protocol (TCP) and 
user datagram protocol (UDP). TCP pro¬ 
vides a connection-oriented service, while 
UDP provides a datagram service. Despite 
the differences between these two trans¬ 
ports, RPC performs the same level of 
function (the same semantics) over each 
of them. RPC function compensates for 
any lack of function in a transport. 

RPC is integrated with other DCE compo¬ 
nents and uses them to provide services 
such as finding servers (through the direc¬ 
tory services) and providing security 
(through authentication and encryption) 
over the communication network. RPC 
uses the DCE threads component to allow 
multiple concurrent calls to the same serv¬ 
er routine. The number of concurrent 
calls is selectable by the server program 
and can be as few as “1.” An alternate 
way of making the same server routine 
available for multiple concurrent calls is 
to implement multiple server processes. 
RPC provides the flexibility to choose one 
or both of these techniques. 

DCE RPC supports a rich set of data types, 
enabling the choice of a natural set of 
parameters for procedure/interface 
definition. 

Benchmarks 

The following benchmarks are used to 
evaluate RPC performance: 

• Null RPC has no parameters or return 
value. Its purpose is to show the base¬ 
line performance cost of an RPC. 

• Variable length array RPC transfers a 
specified number of bytes from a client 
to a server. It is used to observe how 
RPC performs with varying data 
lengths. 

• RPC pipe transfers a specified number 
of bytes from a client to a server, using 
the RPC pipe data type. It is used to 
compare the performances of different 
data types. 

• Security RPC has a null case and a 
data-transfer case (client to server), 
both with a specified level of security. It 
is used to observe the performance cost 
of security. The level of security is 
selected from the choices in Figure 1. 


In addition to the RPC benchmarks, 
another test is used to evaluate the under¬ 
lying transport: 

• TCP/IP Sockets consists of socket send 
and receive commands to transfer a 
specified number of bytes between a 
client and server. It is used to observe 
the base cost of doing a TCP/IP transfer 
for various data lengths. This bench¬ 
mark provides a good estimate of the 
TCP/IP overhead in an RPC transaction. 

Performance Data 

The following sections show measure¬ 
ments taken in the steady-state environ¬ 
ment and do not include load and initial¬ 
ization times. 

Base RPC with TCP Versus UDP. Figures 
2 and 3 compare the base cost of using 
RPC for the two supported TCP/IP proto¬ 
cols: UDP and TCP. The zero-bytes case 
uses the null RPC benchmark, while other 
cases use the variable length array RPC 
benchmark. The TCP protocol for RPC per¬ 
forms better from null to approximately 
2 KB. UDP RPC performs better when 
transferring data lengths of approximately 
2 KB or greater. 

A common characteristic of communica¬ 
tion protocols is that response time 
increases linearly with the data length, 
from zero to a point where response time 
sharply increases. This point approxi¬ 
mates the block or packet size-the size at 
which the protocol breaks up the data. 
Figures 2 and 3 imply that the TCP RPC 
packet size is between 2 KB and 4 KB, 
and the UDP RPC packet size is between 
4 KB and 8 KB. 

Note in Figure 3, as indicated by the flat¬ 
tening curve of the UDP line, for UDP 
RPC, the more data sent in a single RPC, 
the better the performance. This flatten¬ 
ing curve results from the windowing pro¬ 
tocol that DCE RPC implements on top of 
the non-windowed UDP transport. 

The windowing protocol gives UDP RPC a 
significant performance advantage over a 
simpler stop-and-wait protocol by allowing 
multiple RPC packets to be sent before 
receiving acknowledgments. The number 
of packets sent between acknowledgments 
is called the window count. RPC renegoti¬ 
ates a window count on each RPC. The 
RPC packets sent during this negotiation 


do not benefit as greatly from the win¬ 
dowing protocol as those packets sent 
after the negotiation. For this reason, as 
the amount of data increases, greater ben¬ 
efits of the windowing protocol are 
realized. 

For TCP RPC, beyond approximately 8 KB 
of data, it does not matter whether the 
data is sent as a single RPC or blocked 
into multiple RPC requests; the linear 
nature of the TCP line indicates the per¬ 
formance is about the same. This informa¬ 
tion implies that the window count with¬ 
in the TCP transport is maintained across 
RPCs rather than renegotiated on each 
RPC. 

RPC Versus TCP/IP Sockets. Figures 4 
and 5 compare RPC with TCP/IP sockets 
for the UDP and TCP transports. The 
TCP/IP socket measurements approximate 
the amount of time that RPC spends in 
the TCP/IP protocol. The percentage of 
the total RPC time that this represents is 
approximately 42% to 62% for UDP RPC 
and 53% to 68% for TCP RPC. The contri¬ 
bution of the TCP/IP protocol increases as 
the data size increases for UDP RPC and 
decreases as data size increases for TCP 
RPC. 

For comparison purposes, the socket mea¬ 
surements are taken with a 4 KB block 
size; that is, if more than 4 KB of data is 
sent, it is blocked into multiple data sends 
of 4 KB or less. 

Pipes Versus Arrays. Are all data types 
treated alike from a performance perspec¬ 
tive? Two data types are examined here: 
variable length arrays and pipes. One dif¬ 
ference between the two is the interface 
used to program to them. They both start 
out as the standard procedure call model, 
but pipes have an additional callback 
mechanism for getting at the pipe data. 
The callback consists of one or more calls 
from the RPC runtime back to an applica¬ 
tion routine. Through these callbacks, the 
RPC runtime requests the addresses and 
sizes of the data to be transferred. A pos¬ 
sible disadvantage of the callback model 
is that it might be more difficult to pro¬ 
gram to-it breaks up the sequential pro¬ 
gramming flow of the client application. 

Pipes have a performance advantage over 
arrays because the RPC data does not 
have to be immediately available at the 
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start of the RPC. The data can be sent via 
the callback mechanism as it becomes 
available. A new RPC does not have to be 
initiated for each amount of data to be 
sent. 

Figure 6 compares RPC pipes versus vari¬ 
able length arrays for various block sizes. 
Block size refers to the amount of data 
passed to RPC at any single time. For the 
variable length array RPC benchmark, 
block size refers to the amount of data 
passed on each RPC call. For the RPC 
pipe, the block size refers to the amount 
of data passed during each callback. For 
example, sending 32 KB of data blocked 
at 8 KB requires four RPC calls using the 
variable length array RPC, but only one 
RPC call with four callbacks using the RPC 
pipe case. 

Note that pipes and arrays perform at the 
same level if all the data for the array 
case is sent in a single RPC call (not 
blocked). When using pipes, even if the 
data is blocked (at 16 KB in these mea¬ 
surements), performance remains con¬ 
stant; however, when using arrays, if the 
data is blocked into multiple RPCs, perfor¬ 
mance degrades. The amount of degrada¬ 
tion depends upon the block size. 

These conclusions are based on the UDP 
RPC. Similar results, on a different scale, 
were found for TCP RPC. 

Figure 6 reinforces the implied RPC pack¬ 
et size seen in Figure 2. Notice that for 
UDP RPC, 8 KB blocking is not much 
greater than 4 KB. The cost of sending the 
extra packet offsets the gain for sending 
more data per RPC. 

Why choose pipes over arrays? If the data 
is not immediately available, and if 
obtaining the data can be overlapped 
with sending it, we recommend using 
pipes. 

Local Versus Remote. What is the per 
formance difference of an RPC to the 
same (local) machine versus to another 
(remote) machine? Figure 7 compares 
local RPC to remote RPC for various 
machine speeds. Local RPC is equal to or 
faster than remote RPC for data lengths 
up to approximately 40 KB. For larger 
data lengths, remote RPC is faster, and the 
windowing protocol in RPC or TCP/IP 
enables the send and receive processing 
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Figure 4. RPC Versus TCP/IP Sockets (UDP) 
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Figure 5. RPC Versus TCP/IP Sockets (TCP) 



Figure 6. RPC Pipes Versus Blocked Arrays (UDP) 
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Figure 7. Local Versus Remote RPC (UDP) 



Figure 8. RPC Machine Speed Sensitivity (UDP) 



integrity privacy 


Level of Security 

Figure 9. RPC With Security (UDP) 


of the data to execute concurrently. A 
local RPC cannot take advantage of this 
concurrence and is no better off than if 
the windowing protocol were not there. 

RPC Machine Speed Sensitivity. How 
does the machine speed of the client and 
server affect RPC performance? Figure 8 
compares RPC performance for three com¬ 
binations of PS/2 client and server mod¬ 
els, classified as 80->80, 80->95, and 
95->95. In Figure 8, for data lengths 
greater than about 100 KB, the perfor¬ 
mance of the 80->95 combination tends 
toward the performance of the 80->80 
combination. For data lengths greater 
than about 100 KB, the performance of 
the 80->95 combination tends toward the 
performance of the 95->95 combination. 

This comparative performance informa¬ 
tion on RPC over various combinations of 
machine speeds can be used to determine 
whether the receiver or the sender in the 
transfer is the bottleneck that most affects 
performance. As an example, the 95 in the 
80->95 combination performs the role of 
the receiver for data lengths greater than 
about 100 KB. The 95 is also the bottle¬ 
neck, as shown by the fact that the 80->95 
line tends toward the 95->95 line. 

In this example, to improve the perfor¬ 
mance of the RPC transfer for large data 
lengths, the best place to make hardware 
performance improvements is in the 
receiver. However, there is a crossover 
point at which the receiver is so improved 
that the sender becomes the bottleneck. 

RPC with Security 

What is the performance cost of doing a 
secure RPC? Figure 9 compares RPC at 
various levels of security. The security lev¬ 
els connect, call, and packet perform simi¬ 
larly, but a large performance degradation 
exists for packet integrity and an even 
larger one for packet privacy. The over¬ 
head for security-the additional time to 
provide the service-is about the same for 
TCP as UDP. 

Tips and Helpful Hints 

• Use TCP RPC for less than 2 KB of data 
and UDP RPC for more than 2 KB. For 
varying amounts of data, use UDP RPC. 
With UDP, the more data per RPC, the 
better. 
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Use RPC pipes if the data to be trans¬ 
ferred is not immediately available and 



















if the data being sent and received can 
overlap. 

• Try to avoid local RPCs, especially with 
large amounts of data. Why do an RPC 
if it is local? Consider implementing a 
check for the local case and using a fast 
path (perhaps by making the server 
routine a DLL). 

• If trying to improve the performance of 
large data transfers, be aware of which 
machine-sender or receiver-is the bot¬ 
tleneck. Replacing the wrong machine 
may not improve performance much, 
although its capacity to do more con¬ 
current work might increase. 

• Where possible, minimize the use of 
RPCs that have security levels of packet 
integrity and packet privacy 
(encryption). 

Cell Directory Services 

A cell comprises a collection of users, 
computers, and resources that share a 
common set of DCE services. The cell is 
the primary unit of administration in DCE 
and is usually defined such that control is 
focused around a common purpose, per¬ 
haps an organization within a company. 

At a minimum, the cell configuration must 
contain one Security Server, one cell 
directory server, and one distributed time 
server. These servers may be contained in 
one or more machines. Currently, DCE for 
OS/2 supports multiple networks only 
through a global directory agent that must 
be provided by a non-OS/2 machine in the 
cell. The network topology may be quite 
varied within a single cell, ranging from a 
small local area network (LAN) to an 
extensive set of LANs and wide area net¬ 
works (WANs). 

Overview 

Cell Directory Services looks up and man¬ 
ages names of resources in a cell. The 
names are specified in a hierarchical 
arrangement that defines the cell’s name- 
space. A CDS directory appears very much 
like the familiar file system directory, par¬ 
ticularly for UNIX users, or like the OS/2 
and DOS path name without the drive let¬ 
ter and prefix. A directory resides on a 
CDS server in a clearinghouse. The clear¬ 
inghouse can be thought of as a database 
that stores directory information. 

There are essentially three kinds of 
entries in a CDS directory: a directory 


entry, (also called a child pointer), an 
object entry, and a soft link. 

• A directory entry, or child pointer, 
connects the upper levels of a directory 
to another directory immediately 
beneath it in the cell namespace. 

• An object entry represents a resource 
or entity of some sort. It is the end 
point, or leaf node, of the directory. 
Another kind of end point is a junc¬ 
tion. A junction provides a connection 
to special services, such as security and 
the distributed file system, independent 
of the directory service. 

• A soft link is a pointer that provides an 
alternate name (alias) for a directory, 
an object, or another soft link. 

The CDS server responds to namespace 
requests from client applications, which 
includes the other DCE components: RPC, 
security, and DTS. DCE applications use 
CDS for locating its servers and clients. 
Every client has a CDS advertiser and at 
least one CDS clerk. A clerk initiates CDS 
operations and stores the directory data it 
retrieves in a local memory cache. The 
CDS advertiser starts clerks as required, 
locates the CDS servers in a cell, and 
caches their locations for later use. 
Caching allows fast retrieval of previously 
acquired directory information, bypassing 
repeated lookups by the server. Periodi¬ 
cally, the cache is written to disk so that it 
can survive system crashes. The cache is 
also written to disk when the CDS adver¬ 
tiser is stopped. 

CDS Performance Measurements 

The CDS control program (CDSCP) is used 
by a cell administrator, or other users 
with the appropriate permissions, to 
manipulate and manage CDS directories. 
This tool is the basis for the CDS perfor¬ 
mance measurements. The measurement 
cases are defined as follows: 

• Specific commands have been timed by 
repeated execution in a batch program. 
The times obtained are fairly represen¬ 
tative of the response times obtained 
for a manual entry from the keyboard 
after the CDSCP has been loaded. 

• The CDSCP commands selected for mea¬ 
surement are CREATE, SHOW. LIST, 
and DELETE. CREATE and DELETE are 
self-explanatory. LIST simply lists the 
entries at a particular directory level. 


SHOW displays detailed information 
about the entity and its attributes. 

• The commands are timed for directory 
entries and for object entries. 

• The commands are executed at high 
levels of the directory hierarchy. 

Figure 10 shows the base set of measure¬ 
ments for the aforementioned CDSCP com¬ 
mands. Directory operations, in particular 
CREATE and SHOW, are generally more 
time-consuming. 

Figure 11 explores the effects of repetitive 
execution of the SHOW command for direc¬ 
tories and objects. Varying the number of 
entries from zero to 50 indicates a highly 
linear relationship. Figure 12 depicts simi¬ 
lar measurements using the LIST com¬ 
mand. It, too, shows a fairly high linearity 
but with much smaller times. 

Figure 13 shows the effect of concurrent 
workloads on throughput and response 
time. The workload is represented by the 
CDSCP SHOW DIRECTORY command, 
repeated one after another, with no delay 
between executions. Concurrence is 
achieved by adding more machines that 
generate this command stream. The 
throughput saturation occurred at about 
146 SHOW commands per minute. 
Thereafter, the response time increased 
with no gain in throughput. The server 
CPU utilization was well-behaved as the 
load increased, and it was near 100% at 
the throughput saturation point. 

Caching effects on response times for 
CDSCP SHOW DIRECTORY commands, each 
showing four directory entries, were mea¬ 
sured utilizing the SET CDSCP CONFI¬ 
DENCE command. There are three levels: 
high, medium, and low. A confidence set¬ 
ting of high causes the clerk to obtain 
information from only master replicas. 
(Only one master replica-the base direc- 
tory-exists in this test.) A setting of 
medium causes the clerk to get informa¬ 
tion directly from a CDS server. (This is 
the same as the master replica in our test 
setup.) A setting of low means the clerk 
should obtain the information from the 
cache or from the most convenient server. 

Response times for the high and medium 
levels reflect the time required to access 
the server directly for the directory 
information-23.1 and 13.0 seconds, 
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Figure 10. CDS Control Program Base Commands 
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respectively. Response time for the low 
level is only 11.4 seconds because the 
directory data is accessed in the local 
cache. 

Tips and Helpful Hints 

Although the CDS directory looks like a 
normal file system directory, it is much 
more than that; consequently, the 
response time of directory lookups is sig¬ 
nificantly greater in CDS. Thus, CDS 
should be used for its primary purpose of 
providing resource location information 
and should not generally be used for data 
that is more suitable for a file or a 
database. In particular, CDS is designed 
for frequently read information that does 
not change often, so that its caching capa¬ 
bility is exploited. It is not designed to be 
used by applications that need to fre¬ 
quently write data. 

SET CDSCP CONFIDENCE LOW can be 
valuable for processing large amounts of 
repetitive information by a CDS adminis¬ 
trator. It is not useful for applications, 
since it only has a lifetime of the CDSCP 
context. 

Security Services 

DCE Security Services enables clients and 
servers to prove their identities to each 
other, offers integrity and privacy of com¬ 
munications, and controls access to 
resources. 


Figure 11. CDS Control Program SHOW Command 
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DCE Security Services maintains its own 
namespace to ensure that the DCE cell 
remains secure. Clients of the Security 
Services query CDS for binding informa¬ 
tion that enables them to find the 
Security Server. This article concentrates 
on the key security commands, detailed 
below. 

DCELOGIN 

The DCELOGIN command authenticates 
the user to the Security Services by means 
of the user's password, thereby establish¬ 
ing an authenticated network identity. 

The Security Server knows the name 
entered on the DCELOGIN command is the 
name of a principal (user) who is regis¬ 
tered in the security part of the name- 
space. 


Figure 12. CDS Control Program LIST Command 


RGY.EDIT 

The RGY_EDIT command edits the reg¬ 
istry database, which contains informa¬ 
tion about principals, groups. 
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organizations, accounts, and administra¬ 
tive policies. The subdirectories PRINCI¬ 
PAL. GROUP, ORG, and POLICY compose 
the registry space. For example, the 
/.:/ SEC/PRINCIPAL directory contains 
all the principals that have been defined. 

ACL.EDIT 

The ACL_EDIT command manages access 
control lists (ACLs) for all namespace 
objects. An ACL contains a list of entries 
that tell the object with which the ACL is 
associated about the permissions granted 
to a user. The ACL entries collectively 
determine which principals can use the 
object and which operations they are 
allowed to perform on it. Since each ACL 
manager defines the permission tokens 
and appropriate meaning for the objects it 
controls, the actual tokens and their 
meanings vary. 

DCELOGIN Automation 

The DCELOGIN command acquires a DCE 
identity and creates a subshell in which 
that DCE identity can be used when exe¬ 
cuting DCE programs. To automate the 
performance measurements for the login 
function, a less well-known feature, 
DCELOGNE, is used. Although 
DCELOGNE is not shipped with the prod¬ 
uct, you can create it by copying the 
DCELOGIN.EXE file to DCELOGNE.EXE. 
The code behaves differently, depending 
on the program name invoked. 

The DCELOGNE command does not spawn 
a new shell, as does DCELOGIN; both com¬ 
mands, however, create credential files. 
DCELOGNE emits the name of this file and 
then returns; however, the environment 
variables that are automatically set by 
DCELOGIN must be manually set when 
using DCELOGNE . For performance mea¬ 
surement automation, it was shown that 
the manual DCELOGIN from the command 
line takes roughly the same amount 
of time as the sample commands in 
Figure 14 take using DCELOGNE. 


Response Time (seconds) 



Figure 13. CDSCP Show Response Time Versus Throughput 


rem Assume that “e:” 1s the drive DCE is installed on 
e: 

cd \opt\dcelocal\bin 

copy dcelogin.exe dcelogne.exe 

rem Begin “dcelogin” function using “dcelogne” for automation <— 
SET DCEUSRNAME=cell_admin 
SET DCEUSRID=100 
SET DCEGRPID=12 

dcelogne cell_admin -dee- > dcelogne.out 

rem Setup pointer for security credentials cache 

rem SET KRB5CCNAME- 

rem FILE:E:/OPT/DCELOCAL/var/security/creds/<alphanum> 
rem KRB5NAME.SET contains the text “SET KRB5CCNAME=“ 
copy KRB5NAME . SET-rdcel ogne. out KRB5SET.CMD 
call KRB5SET 

rem End “dcelogin” function using “dcelogne” for automation <-- 


Figure 14. DCELOGIN Function Using DCELOGNE for Automation 


Current site is: registry server at /.../cindysworld 
/subsys/dee/sec/master 

cell_admin [none none]:*:100:12::/: : 

princl [groupl orgl]:*:455:226::/:: 

Figure 15. Sample RGY.EDIT View Account Output 


In Figure 14, note that the CELL_ADMIN 
principal is used. To obtain the values for 
DCEUSRID and DCEGRPID, the RGY_EDIT 
program was used to view the accounts. 

Figure 15 is an example showing output 
from the RGY_EDIT program to obtain 
the DCEUSRID and DCEGRPID for the 
accounts CELL_ADMIN and PRINCl. For 
CELL_ADMIN, the DCEUSRID is 100 and 


DCEGRPID is 12. For the account PRINCl, 
the DCEUSRID is 455 and the DCEGRPID 
is 226. 

BIND_PE_SITE Environment Variable 

In release 1.0 of DCE for OS/2, the 
README file suggests that BIND_PE_SITE 
may he set to a non-zero value to improve 
the performance of some security 


functions in a single-cell environment. 

BIN D_P E_S IT E is an environment vari¬ 
able used by Security Services to deter¬ 
mine whether to use CDS to locate the 
Security Server. Its default value is zero, 
which indicates that CDS should be used. 

If changed to a non-zero value. Security 
Services uses a file named P E_S IT E to 
locate the Security Server. The 
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/.../cindysworld 008f6ec0-139b-lca3-831c-10005aa85815 
@ncacn_ip_tcp:129.35.64.148[3 

/.../cindysworld 008f6ec0-139b-Ica3-831c-10005aa85815 
@ncadg„ip_udp:129.35.64.148[] 

Figure 16. Sample PE_SITE File Contents 


Elapsed Time (seconds) 


12 



First Average Average DIR Average 


Figure 17. Key Functions of Security Services 


1. acl__ed1t / .:/sec/pri nci pal/prl ncl 

2. acl_ed1t -addr 008f6ec0-139b-lca3-831c-10005aa85815 

@ncacn_ip_tcp:129.35.64.148[] principal/princl 

3. acl„edit -addr 008f6ec0-139b“Ica3-831c-10005aa85815 

@ncadg_ip_udp:129.35.64.148[] principal/princl 


Figure 18. ACL_EDIT a Principal with Different Binding Examples 


configuration program (MKDCEPM) creates 
this file and stores it in the /OPT 
/DCELOCAL/ETC/SECURITY directory. 
Figure 16 shows two lines from one 
PE_SITE file. In Figure 16, the first item 
is the cell name, followed by the binding 
information for the Security Server. An 
entry is included for each of the support¬ 
ed transport protocols. This information 
is also used to bind to the Security Server 
when the BIN D_P E_S IT E is set to zero 
and the CDS server is unavailable. 

Performance of Key 
Security Commands 

Figure 17 illustrates the performance dif¬ 
ferences obtained by varying the value of 
BIN D_P E_S IT E . Statistics are shown for 
both the first and average login time, 
although most users will log in only once. 


The RGY_EDIT and ACL_EDIT measure¬ 
ments indicate the average entry time to 
begin using these control programs. 

Figure 18 illustrates three different binding 
methods that can be used with ACL_EDIT. 

Figure 19 shows the performance of doing 
ACL_EDIT on a registry server object. It 
compares the three different binding 
methods, as well as the effect of varying 
the value of BIND_PE_SITE. 

In the first example shown in Figure 19, 
no address is specified in the ACL_EDIT 
command. If BIND_PE_SITE is zero, 

CDS is used to locate the object. If 
BIN D_P E_S IT E is non-zero, the first 
entry of the PE_SITE file is used to 
locate the object. 


In the second example, the TCP address is 
specified, indicating that the RPC TCP 
protocol should be used to bind to the 
object. 

In the third example, the UDP address is 
specified, indicating that the RPC UDP 
protocol should be used to bind to the 
object. 

Regardless of the BIN D_P E_S IT E value, 
using the - ADDR option with the RPC UDP 
string binding resulted in the best perfor¬ 
mance for the conditions tested. Note that 
using the -ADDR option eliminates the use 
of /.: / SEC when specifying the object 
name. 

The disadvantage of using BIND_PE_SITE 
set to non-zero, together with the 
ACL_EDIT -ADDR Option, is that they 
require hardcoded information. If the 
location of the Security Server changes, 
the configuration program must be used 
to correctly update the P E_S IT E file and 
the new information used for the - ADDR 
option. While performance is improved, 
usability is somewhat reduced. 

Another disadvantage of setting 
BIND_PE_SITE to non-zero is that it 
might cause functional problems when 
replicated Security Servers are used. 
Currently, replication of the security 
database and daemon is not supported in 
OS/2 DCE 1.0 but may be available on 
other platforms. 

RGY.EDIT Subcommands 

The BIND_PE_SITE variable has no sig¬ 
nificant effect on the RGY_EDIT com¬ 
mands once the control program is 
started. Figure 20 shows performance 
measurements for some common adminis¬ 
trative RGY_EDIT operations using the 
RGY_EDIT control program. Note that 
repetitive operations are considerably 
faster than first-time operations. For this 
reason, it is a good idea to organize a 
large administrative workload by group¬ 
ing similar operations. 

The RGY_EDIT VIEW command is used by 
administrators and other users to view 
accounts, principals, organizations, and 
groups. Figure 21 shows the performance 
for view accounts based on a variable 
number of accounts. 
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ACL.EDIT Subcommands 

Once the ACL_EDIT object is bound, the 
actual commands within the ACL_EDIT 
program perform similarly, regardless of 
the method of binding. For the interactive 
ACL_EDIT operations measured- 
ASSIGN, GET, HELP. LIST. MODIFY. 
DELETE. PERMISSIONS. SUBSTITUTE, 
and TEST-all performed in under a sec¬ 
ond for most elementary cases. 

The ACL_EDIT LIST command is used by 
administrators and other users to view 
ACLs for a particular object. It was deter¬ 
mined that the response time measure¬ 
ments for LIST, based on a variable num¬ 
ber of ACL entries, was a highly linear 
relationship. 

Tips and Helpful Hints 

• Use DCELOGNE, as shown in the sample 
command sequence in Figure 14, to 
automate the DC E LOG IN function. 

• Use BIND_PE_SITE<>0 in a single 
Security Server, single-cell, stable envi¬ 
ronment to improve DCELOGIN, 
RGY_EDIT entry, and ACL_EDIT entry 
performance. 

• Use the -ADDR option on the ACL_EDIT 
command where appropriate. 

• Group similar RGY_EDIT operations. 

For example, if creating multiple 
accounts, first create all the principals, 
then all the groups, then all the organi¬ 
zations, then all the accounts. 

Threads 

The DCE threads facility provides multiple 
sequential paths of execution within a 
process, as opposed to a single path of 
execution available in the traditional 
UNIX model of programming. DCE threads 
is based upon POSIX draft standard 
1003.4a. Other components of DCE use 
threads because of its functionality and 
portability. 

OS/2 has its own threading facility. OS/2’s 
DCE implementation is a mapping of the 
DCE threads APIs to the corresponding 
OS/2 APIs. 

DCE threads APIs and OS/2 threads APIs 
can coexist within the same process, but 
they cannot interoperate. That is, both 
APIs can be used within the same process, 
or even the same thread; however, one set 
of APIs cannot be used to wake up a thread 
that is blocked in the other set of APIs. 


Elapsed Time (seconds) 
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No ADDR - ADDR (TCP) - ADDR (UDP) 


Figure 19. ACL_EDIT a Principal with Different Binding Performance 
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Figure 20. Common RGY.EDIT Operations 
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Figure 21. View Account for RGY.EDIT 
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From a performance perspective, DCE 
threads APIs are a layer on top of OS/2’s 
threads APIs and so must be slower. 
Because an application’s use of threads is 
usually only a small portion of its total, 
the overhead associated with using DCE 
threads is likely to be insignificant. Even 
so, we generally recommend using the 
()S/2 threads APIs to achieve better perfor¬ 
mance, if not porting to other platforms. 

Distributed Time Services 

The primary function of DTS is to syn¬ 
chronize system clocks in the cell to 
ensure that a consistent time is used 
throughout. DTS clients run in each DCE 
machine to provide time services for 
applications and timestamps for RPCs, 
security entities, and CDS object/directory 
creations. At least one DTS server must 
exist in every cell. Multiple servers are 
needed for fault tolerance and for utiliz¬ 
ing the DTS inaccuracy feature. An exter¬ 
nal time provider can be configured when 
very accurate time is required. When 
using a time provider, the inaccuracy for 
all time servers becomes very small, and 
time drift is small. 

DTS Performance Measurements 

DTS measurements were taken to verify 
that DTS has minimal impact on overall 
system performance. With three DTS 
servers and five DTS clients, network traf¬ 
fic was negligible, both before and after 
inclusion of the time services. Although 
there was considerable variation in many 
measurements using the component 
benchmark test cases, the overall average 
was about the same, with and without 
DTS. The variations are attributable to 
normal system background activity. 

Tips and Helpful Hints 

During DCE configuration (MKDCEPM), an 
external time provider should be selected 
from the Time Information section for 
one, and only one, of the DTS servers. 
Selecting the DTS_NULL entry from Time 
Provider Hostname causes the PS/2’s sys¬ 
tem clock to be used as a time source. The 
resulting drift parallels that of the PS/2 
system clock, which is normally around 
two seconds per day. Without a time 
provider, drift can occur at a much higher 
rate, depending on many things, includ¬ 
ing server and network loads. 


Summary of Key Points 

This article has demonstrated the follow¬ 
ing key points: 

Remote Procedure Call 

• Realize that performance varies by 
many factors such as size of data trans¬ 
fer, security levels, transport used, 
pipes versus arrays, local versus 
remote, and hardware used. 

• Use TCP RPC for less than 2 KB of data 
and UDP RPC for more than 2 KB. For 
varying amounts of data, use UDP RPC. 
With UDP, the more data per RPC, the 
better. 

• Use RPC pipes if data to be transferred 
is not immediately available and if 
obtaining it can be overlapped with 
sending. 

• Avoid using local RPCs, especially with 
large amounts of data. 

• Know which machine-sender or receiv- 
er-is the bottleneck. 

• Use RPCs that have security levels of 
packet integrity and packet privacy as 
little as possible. 

Cell Directory Services 

• Avoid using CDS for data that is more 
suitable for a file or a database. 

• Set CDSCP CONFIDENCE to low to 
improve performance when processing 
large amounts of repetitive information. 

Security Services 

• Use DCELOGNE to automate the 
DCE LOG IN function. 

• Use BIND_PE_SITE<>0 in a single-cell 
environment to improve the perfor¬ 
mance of DCE LOGIN, RGY_EDIT entry, 
and ACL_EDIT entry. 

• Use the - ADDR option on the 
ACL_EDIT command when possible. 

• Group similar RGY_EDIT operations. 

Threads 

• Use OS/2 threads for performance and 
DCE threads for portability. 

Distributed Time Services 

• Running DTS minimally impacts overall 
performance. 

• Configuring with an external time 
provider improves accuracy and mini¬ 
mizes drift. 
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VisualAge: 

Its Features and Virtues 


This article describes the overall capabilities of VisualAge, IBM's 
recently announced client/server application development tool 
VisualAge gives its users a powerful new way to create applications 
that run either on stand-alone systems or in a distributed environment 

This article describes the basic principles of client/server computing 
and visual programming in the context of how the VisualAge tool sup¬ 
ports these philosophies and features. 


and data directly into the computer cir¬ 
cuitry. This “hard-wiring” was the first 
generation of programming. Using 
devices that read the binary data did not 
help much, because calculating absolute 
jump and data addresses consumed a 
great amount of time and effort. It was 
very difficult to create and change these 
programs. 


This article was written during beta testing of the product and may 
describe features not included in the released product, which is sched¬ 
uled for release in early 1994. Additionally, features not mentioned in 
this paper may be included in the generally available product Screen 
images may also have changed between beta testing and general avail¬ 
ability. Consult the product announcement for exact details of the 
offering. 


Second-generation programming lan¬ 
guages were symbolic macro assemblers. 
Although assemblers freed the program¬ 
mers from tedious address assignment 
chores, the tedium remained. Program¬ 
mers still had to calculate storage require¬ 
ments and make sure that the machine 


T his is the era of 

fourth-generation com¬ 
puting languages. People 
get excited about advances in 
technology. You might be one 
of them. On the other hand, 
you may be asking “What is a 


Tony Colle 
Skill Dynamics 
(an IBM company) 
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fourth-generation language? 
What were the first three?” 

Modern computer program¬ 
ming began in the late 1940s 
and 195()s with specially 
trained scientists who knew 
the intimate details of the 
computers on which they 
worked. At first, they literally 
wired the binary instructions 
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could properly address the data and pro¬ 
grams. In addition, each architecture not 
only had its own machine language, but 
also needed its own assembler and assem¬ 
bly language. Moving to another system 
usually meant rewriting all of the code. 

The need for a higher-level program repre¬ 
sentation led to the third-generation pro¬ 
gramming languages, the compiler lan¬ 
guages. These languages use general alge¬ 
braic or English-like statements to repre¬ 
sent operations. The compiler converts 
these statements into the actual 
machine-language code. It also lays out 
the data and ensures proper addressability 
of all program and data blocks. 

Even with third-generation languages, pro¬ 
grammers still needed specialized skills. 
They had to understand the computer and 
its languages. They needed to use complex 
macro or utility programs to do even the 
simplest business functions. They found 
that accessing data in a database was not 
a trivial matter. 

Programmers still coped with high levels 
of frustration, because the computer did 
only what it was told to do. Indeed, the 
eternal hope of programmers was that the 
next language release would contain the 
“do-what-I-meair instruction or utility. 

Business Logic 

With the advent of third-generation lan¬ 
guages, businesses started to appreciate 
the value of the computer. No longer was 
it a tool just for the scientists and 
academicians. 

Many parts of a business are repetitive, 
predictable, and heavy in calculations or 
data movement. These pieces of the busi¬ 
ness are perfect for computer automation. 

In analyzing a business, it is important to 
extract the essential business processes, 
separating what the business does from 
how the business does it. The presenta¬ 
tion of data, the medium of data storage 
(tape versus disk, for example), and the 
communications media are “how” process¬ 
es that change rapidly as technology 
advances. In contrast, the business logic 
pieces-“what” the business does-change 
very little, if at all. Tools that capitalize 
on maintaining stable business logic while 
accommodating the ever-changing 
presentation and storage technology give 


a distinct advantage to the businesses that 
use them. 

Fourth-Generation Languages 

Enter fourth-generation languages. Some 
fourth-generation languages are “non-pro¬ 
gramming” languages that let the average 
user set up business logic situations with¬ 
out doing any programming. For example, 
using a spreadsheet, a user can do a 
what-if analysis simply by changing some 
numbers and requesting a recalculation. 
Using visual programming tools, a user 
can lay out the interface for a complex 
application, all the while being able to see 
what it will look like. Using composition 
tools, users can define how business logic 
components interact with each other to 
perform critical business functions. 

It is in this fourth-generation language 
arena that VisualAge steps in as an appli¬ 
cation builder. VisualAge helps users and 
development professionals alike create 
better applications faster through new 
technology we will describe below. 

VisualAge—What Is It? 

VisualAge is an object-oriented, visual¬ 
programming, client/server application 
builder. Using the concepts of team pro¬ 
gramming and rapid prototyping in an 
iterative development cycle, VisualAge can 
help your organization produce a stand¬ 
alone or networked application. It is built 
upon the powerful object-oriented envi¬ 
ronment provided with the IBM Smalltalk* 
language. VisualAge lets you either build 
your applications from the ground up, 
extend an existing application, or take an 
existing application and build a daughter 
application that is like the old applica¬ 
tion, but with some differences. 

VisualAge uses an object-oriented base for 
application development; however, it 
shields new users from needing to be pro¬ 
ficient, or even conversant, in object- 
oriented technology until they need to 
develop more complex applications. 

This all sounds great if we understand the 
jargon. But what does it all mean? Let’s 
see how VisualAge incorporates these 
concepts. 

Object-Oriented Technology 

Traditional programming forced program¬ 
mers to think in terms of what they wanted 
computers to do. This activity-oriented 


philosophy sees programs as one big algo¬ 
rithm analogous to a recipe: the program’s 
inputs are the ingredients, and the pro¬ 
gram describes how these inputs should 
be separated, sifted, beaten, folded, 
mixed, and baked (sometimes only 
halfway) to produce the desired output. 

On the other hand, object-oriented tech¬ 
nology changes this philosophy by allow¬ 
ing users and programmers of the system 
to think in terms of the things, or objects, 
that the business uses and how they 
interact. 

Each object has its own behavior and 
characteristics. An object can be a report, 
a customer, or even an integer-almost 
any person, place, thing, or concept that 
can be described by a noun or a short 
phrase. 

By looking at similarities between differ¬ 
ent classes of objects, a system designer 
can hierarchically organize the objects in 
your system according to their similari¬ 
ties. For example, the 90-Day-Late Report 
may be almost exactly like the standard 
Accounts Receivable Report, but limited to 
certain data. 

Object-oriented technology allows design¬ 
ers to define one class of objects, such as 
reports, as being similar to another, but 
with some differences. Then implementers 
only need to program those differences 
while the technology handles the similari¬ 
ties. Because of this focus on similarities 
and differences, object-oriented program¬ 
ming is often called “programming by dif¬ 
ferences.” Figure 1 shows a sample hierar¬ 
chy of reports. 

In Figure 1, the top of the hierarchy 
defines a report’s characteristics. The 
report defined at the top would reflect 
the general layout for company reports. 
The items (classes) under it describe spe¬ 
cific reports. Notice also that the hierar¬ 
chy shows that the 90-Day-Late Report is 
like the Accounts Receivable Report. 

As a starting point, VisualAge gives you a 
rich set of pre defined classes of objects. 
You can either build classes that you tai¬ 
lor from the ones that come with the sys¬ 
tem, or you can start from scratch to 
define classes for your unique business 
objects. Should a vendor make a library of 
object classes available to you, VisualAge 
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Figure 1. Part of a Sample Object Class Hierarchy 
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lets you easily incorporate those classes 
into your environment and, therefore, 
into your applications. 
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Visual Programming 

If you want to write your own code (and 
sometimes code is required), VisualAge 
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uses the scripting language provided by 
IBM Smalltalk. The real power of 
VisualAge, however, comes from its ability 
to describe a business application, not by 
writing code, but rather by visually con¬ 
necting the pictures, or icons, that 
describe the parts of your business. 


VisualAge gives you a layout surface that 
looks like an empty canvas or piece of 
drawing paper. You construct your appli¬ 
cation by placing your icons on this 
surface. 

VisualAge allows you to connect the icons 
by drawing lines. You draw the lines as 
you tell it which components are related 
and how they are related. For example, 
you may draw a line showing that the 
“name” of the employee object is also a 
part of the W-2 tax form. While drawing 
these lines, VisualAge keeps the name of 
the employee and the name on the W-2 
synchronized. Other connection requests 
might cause some kind of action to occur 
in your application, such as storing data 
to a file. 

You can select standard components from 
a parts palette and then graphically 
describe your application, the screens that 
the application will display, and the busi¬ 
ness logic that it will use. Figure 2 shows 
a sample layout surface for an application 
being developed using VisualAge. 

Programmers may be involved in writing 
business logic, such as a COBOL dynamic 




























































Figure 3. Sample Client/Server Environments 


link library (DLL), or in building a remote 
database. Using VisualAge connections 
between these components that program¬ 
mers provide, you can build your applica¬ 
tion in the VisualAge development envi¬ 
ronment. You graphically describe how 
the new components relate to each other 
and to other components, sometimes 
without ever touching any code. 

While the databases or programs are 
being developed, you can use the 
Smalltalk scripting language to build a 
code stuh-QO(ie that emulates the not-yet- 
written functions for prototyping or test¬ 
ing purposes. Once you are ready to 
incorporate the new components, simply 
remove the stub and connect the real 
components. 

Client/Server 

Building a stand-alone application for a 
workstation that uses only locally avail¬ 
able functions and data may satisfy many 
needs, but usually a time comes when you 
need data from another system to be 
available on the local area network (LAN) 
or on a remote host. 

This is when VisualAge seems like a 
knight in shining armor. Supporting a 


number of databases with equal ease, 
both locally and remotely over several dif¬ 
ferent kinds of networks to any number 
of host systems, VisualAge makes it almost 
effortless to build an application in which 
your workstation client communicates 
with a remote server. 

Client/server (sometimes called 
requester/hroker) is a term used fre¬ 
quently today. In the VisualAge context, if 
your workstation needs to access data or 
function that resides on another system, 
your application is the client of that serv¬ 
er. Each application may require a differ¬ 
ent server on a different host, but 
VisualAge handles the transaction with 
minimal user involvement. Figure 3 shows 
some possible client/server environments. 

Team Programming 

VisualAge can be used by an individual 
describing a single application, or by a 
group of people sharing development 
responsibility over a LAN. VisualAge uses 
a library registration and management 
process. It ensures that only certain peo¬ 
ple can modify specific parts (compo¬ 
nents) of the application, that no two peo¬ 
ple can simultaneously modify the same 


copy of a part, and that when you start 
developing a part, the cleanest, most 
up-to-date parts are available for your 
use. Figure 4 shows one possible team 
environment. 

Rapid Prototyping and 
Iterative Development 

Your organization can quickly prototype 
an application so that users can see and 
understand its presentation, function, and 
products before the formal development 
process starts by bringing together appli¬ 
cation users, system designers, and busi¬ 
ness logic specialists. 

As users of the application describe what 
they need, business logic specialists ana¬ 
lyze the current set of components avail¬ 
able through VisualAge, noting which 
ones to enhance, which to copy and modi¬ 
fy, and which to create. Then system 
designers, who understand the business 
operating environment, can temper expec¬ 
tations as they collect requirements for 
new hardware and software components. 
The result is a better understanding of the 
business needs and more realistic expecta¬ 
tions of what the system can provide for 
everyone concerned. 
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Figure 4. Team Programming Environment 
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Figure 5. Iterative Development 
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Working within this framework, you can 
model the system using VisualAge, then 
test it by using dummy parts to emulate 
function that must be created. You can 
center the development process around a 
set of these planning, producing, and 
reviewing iterations. As each iteration 
brings in newly created parts to test for 
compatibility, this process verifies the 
functions of the system from the business 
perspective. As the system grows, every¬ 
one gains experience with its functions 
while quickly incorporating changes 
based on human factors and business 
needs. 

When the cycles are finished, the end 
product meets the users’ requirements. 
You’ve successfully completed an 
application! 

Figure 5 shows how a project loops 
through planning and producing phases 
to create the end product. 

VisualAge Concepts 

VisualAge builds its visual programming 
development and run-time environment 
on object-oriented (00) technology. For 
non-object-oriented development shops, 
the good news is that VisualAge can ease 
the transition into object technology. But 
people who know 00 can easily unleash 
the full power of this technology with 
VisualAge. 

Object-oriented technology encourages, 
and in some cases even enforces, good 
software engineering development prac¬ 
tices. The foremost of these practices is 
encapsulation. 

Encapsulation allows software objects to 
be used freely in a development or 
run-time environment, while protecting 
the integrity of the data associated with 
the object. As almost any software devel¬ 
oper knows, data corruption, either acci¬ 
dental or through poor design, is one of 
the major causes of software problems. 
Encapsulation protects the data from acci¬ 
dental destruction or improper modifica¬ 
tion by providing a well-defined interface 
to the data. It is only through this inter¬ 
face that you can access the data, either 
for view or modification. By preventing 
the person who is using the object from 
directly modifying the data, data integrity 
is virtually guaranteed, and problems are 
reduced or even eliminated. 


Figure 6. Public Interface Editor Screen 

Building on the concept of an encapsulat¬ 
ed object, VisualAge adds a well-defined, 
standard public interface that all 
VisualAge components understand. When 
the person building an application access¬ 
es a standard component or builds a new 
component for the system, VisualAge uses 
its standardized public interface for all 
communication with the object. This inter¬ 
face consists of publicly available 
attributes, actions that the component can 
be asked to perform, and events by which 
the object can tell the other objects that 
some specific thing has happened. 

By recognizing an object’s public inter¬ 
face, objects in the system can access 
another object’s attributes, request the 
object to perform some action, or respond 
to an event that occurred in some other 
object. Other objects that were waiting for 
the event to happen can then act appro¬ 
priately. Figure 6 graphically shows a com¬ 
ponent’s public interface. 

You can access an object’s attributes to 
either set or get the value; therefore, each 
object has “get” and “set” functions for 
each publicly available attribute. Although 
this may sound like a violation of encap¬ 
sulation, this access actually goes through 
the encapsulated interface. It has all of 
the protections that the system automati¬ 
cally provides (such as synchronizing data 
types), plus it enables you to add any¬ 
thing you may wish (such as range-check¬ 
ing and data validation). 


If you must define a component’s behav¬ 
ior to a degree not possible by simply 
describing its constituent components and 
their relationships, VisualAge provides an 
editor that allows you to describe behav¬ 
ior using its scripting language, IBM 
Smalltalk. Smalltalk, a pure object-orient¬ 
ed language, is the underlying language in 
the VisualAge environment (which is dis¬ 
cussed in the next section). Using 
Smalltalk when necessary, you-the 
VisualAge component builder-can 
describe behavior anywhere. By using 
built-in Smalltalk features to let objects 
communicate among each other, and by 
directing data movement and manipula¬ 
tion, you can work with data any way you 
want or need. 

Even though VisualAge lets you drop 
down into the IBM Smalltalk language 
when you need to, it is not always neces¬ 
sary to write code. You can describe many 
applications by using pre-built parts and 
describing their relationships to one 
another. If your business logic is already 
written in a different, third-generation 
language, you can easily incorporate those 
DLLs into your application. 

You can access logic and data that reside 
on a different host by using standard 
VisualAge components. This simplifies the 
client/server application in a VisualAge 
environment; accessing a database on a 
remote host, for example, becomes as easy 
as accessing data on your workstation. 
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CalendarManaaer - Scriot Editor View 



Figure 7. Script Editor Sample 


VisualAge also arranges components in 
other categories that provide local and 
remote database access to: 

• A variety of database managers such as 
the IBM DATABASE2* (DB2) family, as 
well as non-IBM database managers like 
Oracle* and Sybase* 

• Third-generation language (such as C 
and COBOL) DLLs 

• Communication, through advanced pro- 
gram-to-program communication 
(APPC), transmission control 
protocol/internet protocol (TCP/IP), 
CICS* ECI, NetBIOS, and emulator 
high-level language application pro¬ 
gramming interface (EHLLAPI) 

• Models for standard Smalltalk compo- 
nents-so you don't need to know how 
to use them directly (multimedia com¬ 
ponents are also available) 


The VisualAge Environment 

VisualAge comes in two flavors: stand¬ 
alone and team. Both environments have 
the same development features. In addi¬ 
tion, the team edition provides version 
and release control, making application 
packaging easier than with the stand¬ 
alone version. The team edition also sup¬ 
ports, as its name implies, a group of people 
working on the same application at the same 
time. 

VisualAge lets you define your applica¬ 
tions and their various parts. Once you 
have chosen names for these visual and 
non-visual components, you may use one 
of three standard editors that VisualAge 
provides to create and subsequently modi¬ 
fy the components. 

Composition Editor 

The Composition Editor lets you visually 
create the components of the application 
by describing the sub components and 
their relationships. It is the heart of 
VisualAge development. You create all 
visual components with the Composition 
Editor by selecting standard Common 
User Access (CUA) parts (such as panes 
and buttons) and business logic compo¬ 
nents from menus, then organizing them 
on a layout surface, as shown previously 
in Figure 2. 

Public Interface Editor 

The Public Interface Editor lets you define 
the publicly available attributes that other 


components can access, the actions anoth¬ 
er part can ask this part to perform, or an 
event that this component will report. 
Frequently, the actions and events you 
define here will be expanded and given 
their behavior using the Script Editor (dis¬ 
cussed next). A sample definition appears 
in Figure 6. 

Script Editor 

The Script Editor lets you define any need¬ 
ed Smalltalk code. For example, it is use¬ 
ful for defining VisualAge scripts that can 
cause the workstation to beep when a 
user presses a button or exceeds a limit. 
Additionally, you can use the Script Editor 
to define the complete behavior for any 
part that you create in Smalltalk. These 
parts might be business logic or prototype 
emulations of future components. Figure 7 
shows a sample of the Script Editor. The 
IBM Smalltalk language was written to 
conform to the proposed ANSI standard 
for Smalltalk. This standard provides 
portability of Smalltalk code across multi¬ 
ple platforms. 

VisualAge Components 

VisualAge comes with a rich set of 
ready-to-use components. Earlier, it was 
mentioned that VisualAge has a wide vari¬ 
ety of CUA components. For convenience, 
and to reduce the number of things you 
must remember at one time, VisualAge 
categorizes all components. The CUA cate¬ 
gories provide buttons, data entry fields, 
lists, menus, notebooks, and other types 
of windows. 


In addition to the components that come 
with the product, VisualAge has a very 
easy mechanism that lets you create your 
own categories and add components to 
them. You can easily incorporate compo¬ 
nents created by one segment of an enter¬ 
prise, or purchased from a vendor, into 
the VisualAge environment. 

VisualAge Virtues 

VisualAge is a complete application devel¬ 
opment and run-time environment. Unlike 
other visual programming tools, VisualAge 
provides the full power of object-oriented 
technology to its users. Although experi¬ 
ence with this technology and the 
Smalltalk language is most helpful, if your 
shop is not fully versed in this technology, 
VisualAge can ease your application devel¬ 
opers into using the technology’s concepts 
and avoiding many of the perceived com¬ 
plexities. If your organization is capable 
of exploiting object technology, however, 
every feature is readily available. 

Because application users can build all or 
most of the business application them¬ 
selves, sometimes with no additional pro¬ 
gramming, they are ensured that they 
have the applications they want and need. 
Rapidly prototyping applications can pro¬ 
vide useable and efficiently laid-out user 
interfaces early in the development cycle. 
Since layouts are easily changed with 
VisualAge, it becomes an easy task to try 
different input fields or button types, 
then play around with their locations. 
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Prototyping also lets the people who will 
use the final product get a feel for the 
actual functions they will use. Training 
becomes easier, because the users now 
know what it takes to use the new system. 

Freeing up highly trained programming 
personnel to focus on programming 
instead of building user interfaces can 
affect resources positively. Since 
VisualAge’s technology allows you to cre¬ 
ate applications simply by selecting com¬ 
ponents and defining the relationships 
between them, you don’t have to be a 
highly skilled programmer to define how 
an application is put together or what the 
user interfaces look like. 

Compared to most languages and develop¬ 
ment environments, laying out a GUI or 
application flow with VisualAge is almost 
trivial. Many tasks that can take several 
days with traditional programming lan¬ 
guages take, with some practice, only min¬ 
utes to a few hours with VisualAge. Even 
beginners can be quickly productive using 
VisualAge. As a result, I/S shops can focus 
scarce programming resources on the 
more complex tasks such as creating 
databases, database views, or complex 
business logic components that require 
traditional programming. 

But the greatest benefit is an increase in 
the quality of the end products. Everyone 
profits when the users quickly get a sys¬ 
tem that performs the business tasks and 
presents the data in a useable format. 
VisualAge development in conjunction 
with good design practices helps ensure 
your organization gets the robust applica¬ 
tions it needs in a timely manner. 

VisualAge today is a very useful product, 
and much more will become available in 
the future. 

Additional Information 

If you want to learn more about how to 
use the VisualAge product, Skill Dynamics, 
IBM’s education company, has an entire 
suite of courses that do everything from 
introducing you to the product to making 


Definitions 

Object-Oriented Technology 

A technology that focuses on how the data and processes within a system or an 
application relate to each other. Traditional programming tends to focus on one or 
the other, but rarely on both. Object-oriented programming (OOP) treats data, plus 
the processes that work on or with the data, as a unit called an object and models 
the way that objects interact. 

Visual Programming 

A method of constructing a program or application by selecting pre defined compo¬ 
nents (the pieces that make up the program) and graphically describing the way the 
components interact, using some kind of “What You See is What You Get” 
(WYSIWYG) editor. 

Client/server 

A form of distributed computing that allows one system to send a request to 
another, possibly different, system and receive a response that can be understood 
and processed by the first system. Logically, the process appears to the user or to 
the application as a single system. 

Team Programming 

A concept wherein several people can simultaneously work on one project. 

Although not new in the realm of host-based computing, personal computer-based 
program development was, due to a lack of communication capability between sys¬ 
tems, a single-person activity. In a team programming environment, people pool 
their independent work efforts as an integrated unit, complete with library manage¬ 
ment, to accomplish the group objective of a working system. 

Rapid Prototyping 

Using the visual interfaces and possibly the skeleton code behind the interfaces, a 
working prototype of a system is constructed quickly to show the user community 
the look and feel of a new application. 

Iterative Development 

A process of specifying and huilding parts of a large project by breaking the project 
into smaller pieces and iterating through planning, production, and evaluation 
phases. Each iteration refines the process, exploits new knowledge of the changing 
business environment, and uses feedback from earlier iterations to produce a better 
product. 


you a proficient user. Object technology 
and Smalltalk programming courses are 
also available. In the US, contact Skill 
Dynamics at (800) IBM-TEACh (426-8322) 
for information. 

Technical and product information is also 
available on TalkLink from Advantis. In 
the US or Canada, call (800) 547-1283 for 
information on TalkLink. CompuServe 
users can enter GO VISUAL. 


Tony Colie currently 
leads the development 
and delivery effort for 
Skill Dynamics’ 
VisualAge education. 
He has been develop¬ 
ing and teaching 
object-oriented and 
software engineering 
courses for over three 
years. Before joining IBM’s education group, Tony 
spent 16 years as an application and system 
developer with various IBM units. He has a BA in 
applied mathematics from the State University of 
New York at Binghamton and an MS in biomedical 
computer science from The Georgia Institute of 
Technology. 
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LITTLE SOLUTIONS 


Little Solutions 


Creating a Scrollable OS/2 
Window 

While entering commands in an OS/2 
window, have you ever wished you could 
see what has just scrolled off the screen? 
The information helow explains how to 
set up an OS/2 window you can scroll. 

You can create either a permanent one or 
a temporary one. 

Setting Up a Permanent Scrollable 
Window 

1. Select an OS/2 command window icon 

2. Press your right mouse button to open 
the Settings Notebook 

3. Enter the following information in the 
Parameters field of the Settings 
Notebook: 

/K mode 80,100 

4. Close the Settings Notebook 

Testing 

1. Open the OS/2 command window that 
you have just modified 

2. Type several commands (a few DIR 
commands will do) 

3. Place your pointer on the scroll bar to 
scroll up. You now have a scrollable 
window. 

You can also set up a scrollable window to 
use temporarily. You do this by creating a 
command file. Once you’ve created it, run 
the command file and a scrollable window 
will be created. When finished, close the 
OS/2 window. 

Setting Up a Temporary Scrollable 
Window 

1. Use an editor like EPM (enhanced 
editor) or E to open a window 

2. Enter the following information into 
your document: 

MODE 80.100 

3. Save the document as M. CMD 


Testing 

1. From an OS/2 command line, enter M 

2. Use the window 

3. When you are done, just close the 
window. 

-Mike Ponce cle Leon, IBM 's Personal 
Systems Competency Center 
Roajioke, Texas 

Automating NetWare Login with 
OS/2 2.x 

As a NetWare Q&A responder, I often see 
questions from customers who want to log 
in to a NetWare server before the 
Workplace Shell is running. Usually, they 
want to do this so that icons for programs 
residing on the server will appear when 
the desktop starts. Unless they have 
logged in before the Workplace Shell 
starts, these icons will revert to the 
default program icon. 

Provided that you wait for the NetWare 
Requester to initialize, you can log in 
from the CONFIG.SYS. Figure 1 shows a 
small CMD file to do this. 

NOTE: before modifying your configura¬ 
tion, you should save your existing config¬ 
uration files (i.e., CONFIG.SYS, 
0S2SYS.INI. and 0S2.INI). 


To activate this program, add the follow¬ 
ing line to your OS/2 CONFIG.SYS after 
the NetWare Requester statements: 
CALL=D:\0S2\CMD.EXE /K D: 
\NETWARE\L.CMD 

This assumes you have named the file 
L.CMD and placed it in your NETWARE 
directory. Replace D: with the drive 
where you have installed OS/2. 

NOTE: Using this configuration, you will 
not be able to execute CAPTURE state¬ 
ments from a login script. Attempting to 
do so can lock up your machine. 

The sample program in Figure 1 assumes 
that the OS/2 utilities exist on the server. 
If they do not, you can change the IF 
statement to look for L : \ LOGIN .EXE and 
change the actual LOGIN statement to 
D:\NETWARE\L0GIN. If you are using the 
NetWare 4.x version of LOGIN, but are a 
bindery client, be sure to use the /B 
option with LOGIN. 

When OS/2 is starting, you will see the 
message Wai ti ng for L: drive... 
This message may be displayed for a 
minute or more, depending on the speed 
of your machine and the speed of the 


@ECH0 OFF 

@ECH0 Waiting for L: drive. 

:START 

IF EXIST L:\0S2\L0GIN.EXE GOTO MIDDLE 

GOTO START 

:MIDDLE 

@ECH0 Logging in... 

REM Replace ‘d:' below with your boot drive 
d: 

L: 

CD 0S2 

REM Replace ‘server/user* with your server and user name 

L:L0GIN server/user 

IF ERRORLEVEL 1 GOTO MIDDLE 

:ENDIT 

EXIT 
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Figure 1. NetWare Login Program: L.CMD 






network. Normally, the requester finishes 
its initialization during the startup of the 
Workplace Shell; however, for this process, 
you have to wait for it to finish. 

—Aubrey Turner, IBM’s Personal Systems 
Competency Center 
Roanoke, Texas 

Changing the Resolution in 
WIN-OS/2 Full-Screen Sessions 
(SVGA and XGA) 

For those of you using Windows applica¬ 
tions under OS/2 2.1,1 have discovered 
an easy way to change the resolution for 
your WIN-OS/2 full-screen sessions. If you 
have attempted this before, you know 
that it involves swapping diskettes and 
rebooting. The procedure below, however, 
describes how to change the resolution by 
editing only one or two lines of the 
WIN-OS/2 SYSTEM.INI file. 

To begin, open your WlN-OS/2 
SYSTEM. INI file using the OS/2 system 
editor (or another editor). The 
SYSTEM.INI file is located in the 
\0S2\MD0S\WIN0S2 subdirectory. If you 
have installed WIN-OS/2 in your D: parti¬ 
tion, go to an OS/2 command line (full 
screen or windowed) and type the 
following: 

[D:\]E D:\0S2\MD0S\WIN0S2 
\SYSTEM.INI 

You should now have the SYSTEM.INI 
file in the OS/2 system editor. 

XGA 

First, scroll down to the bottom of the 
SYSTEM.INI file. Near the bottom, you 
should see the following section: 

[XGA_D1splay] 

XGA_Resolution=2 

Here comes the easy part. 

For 1024 X 768 resolution, the line 
XGA_Resol uti on should look like: 

XGA_Resol uti on=2 

For 640 X 480 resolution, the line 

XGA_Resol uti on should look like: 
XGA_Resolution=l 


SVGA 

I have tested this procedure on an IBM 
ValuePoint* 433DX, which has the TSENG 
chipset. For other SVGA adapters, the pro¬ 
cedure should be similar, but testing is 
recommended. Before you begin this pro¬ 
cedure, make sure you have installed 
either the SVGA device drivers that came 
with ()S/2 or the ones provided by your 
adapter vendor. 

Scroll down to about the middle of the 
SYSTEM.INI file. At the bottom of the 
[boot .descri ption] section, you will 
see the following two lines, which provide 
1024 X 768 X 256 resolution: 

display.drv=1024x768x256 Large 
fonts IM ET4000 

sdisplay.drv=1024x768x256 Large 
fonts IM ET4000 

NOTE: The initial OS/2 2.1 installation of 
SVGA does not install full SVGA support, 
but rather installs VGA support at 640 x 
480 X I6 resolution. This happens 
because the initial installation phase does 
not support MVDM DOS. This support is 
needed to run the DOS SVGA query pro¬ 
gram, which establishes the capabilities of 
the display adapter and monitor. To 
install full SVGA support, including the 
higher SVGA resolutions, you must install 
the SVGA display drivers once you’ve 
installed OS/2 2.1. To do this, run 
DSPINSTL from an OS/2 command 
prompt. DSPINSTL is a special install pro¬ 
cedure much like Sel ecti ve Instal 1, 
but DSPINSTL installs only video 
adapters. 

To repeat, for 1024 x 768 x 256 resolu¬ 
tions, the lines should look like this: 

display.drv=1024x768x256 Large 
fonts IM ET4000 

sdisplay.drv=1024x768x256 Large 
fonts IM ET4000 

For 800 X 600 x 256 resolution, change 
the lines to: 

display.drv=800x600x256 Large 
fonts IM ET4000 

sdisplay.drv=800x600x256 Large 
fonts IM ET4000 


And for 640 x 480 x 256 resolution, 
change the lines to: 

display.drv=640x480x256 Large 
fonts IM ET4000 

sdisplay.drv=640x480x256 Large 
fonts IM ET4000 

If you have a different chipset for your 
SVGA adapter, you may have to alter the 
lines described above. Just ask your 
adapter vendor for the proper settings to 
change resolutions. 

For the changes to take effect, you will 
need to close down and restart your full¬ 
screen WIN-OS/2 session. The great thing 
is that the changes will not affect your 
windowed/seamless WIN-OS/2 session 
(the one on the OS/2 desktop). This 
means that you can have a full-screen 
WIN-OS/2 session running at one 
resolution while the windowed WIN-OS/2 
session runs unaffected on the OS/2 
desktop. 

—Tim Burleson, IBM’s Personal Systems 
Competency Center 
Roanoke, Texas 

How to Access Memory Above 
16 MB on an OS/2 2.1 LAN 
Server 3.0—Advanced Platform 

To tell IBM LAN Server to use the memory 
above 16 MB, you must put a line in your 
CONFIG.SYS. It’s the USEALLMEM com¬ 
mand that lets LAN Server 3.0-Advanced 
use the memory above 16 MB. (NOTE: The 
following sample line is for either the IBM 
Token-Ring I6/4A adapter or the IBM LAN 
Streamer* 32 adapter. Be sure that your 
adapter will support memory above 
I6 MB.) 

IFS=C:\IBM386FS\HPFS386.IPS 
C:\IBM386FS\HPFS200.386 
/I:D:\IBMLAN /USEALLMEM 

-Marty Dee, IBM’s Personal Systems 
Competency Center 
Roanoke, Texas 
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Questions 

NetWare 

I recently installed a PS/2 195 server 
with NetWare 3.11, 64 MB of memory, 
a 32-bit streaming token-ring adapter, 
and Sybase SQL server NetWare load¬ 
able module (NLM). NetWare was 
accessing memory only to the 16 MB 
line, so we put the AUTO REGISTER 
command in the AUTOEXEC. NCF. That 
helped, but we still can't access all of 
the 64 MB of memory. 

What should the AUTO REGISTER com¬ 
mand look like? Why do we have to 
use the AUTO REGISTER command at 
all on a 195? 1 thought Micro 
Channel* machines didn't need the 
AUTO REGISTER command to access 
memory above 16 MB. 

With Micro Channel machines, you should 
not use the AUTO REGISTER MEMORY 
ABOVE 16 MEGABYTES parameter. You 
should use the REGISTER MEMORY param¬ 
eter, which is a server console command 
with the following format: 

REGISTER MEMORY start length 

“Start” is the starting hexadecimal 
address where the memory beyond 16 MB 
begins, and “length” is the hexadecimal 
length of the memory beyond 16 MB. For 
example, you might use this command: 

REGISTER MEMORY 1000000 
3000000 

You may add this line to the 
AUTOEXEC. NCF file to have the memory 
registered automatically when the file 
server boots. 

This parameter is documented in the 
NetWare 3N1 System Administration 
manual (included with NetWare 311) on 
pages 216 through 218. The AUTO 
REGISTER MEMORY ABOVE 16 
MEGABYTES parameter is documented on 
page 2l6 of the same manual. 

PERSONAL SYSTEMS • JANUARY/FEBRUARY 1994 


and Answers 


We are receiving the following error 
message when we perform a directo¬ 
ry search on a mapped NetWare drive: 

Network Broadcast Message 1.1.90 
You exceeded your outstanding 
NCR directory search 

Please tell me how to correct this. 

This message is often caused by applica¬ 
tions that do not handle directory search¬ 
es according to Novell’s recommendations. 
There are two ways to resolve this prob¬ 
lem: 

1. Rewrite the application according to 
Novell recommendations. 

2. Type the following command at the 
file server console (also add this 
command to the AUTOEXEC. NCF): 

SET MAXIMUM OUTSTANDING 
NCR SEARCHES = 100 

Please note that this set parameter 
requires 24 bytes per directory per user. 

For example, if you have 250 users and 
100 directories, the file server will require 
600 KB just for the search tables. 

For more information on how to rewrite 
your application, please call Novell at 
(800) RED WORD (733-9673). 

D0S„UMB ON 


When I try to run Lotus 1-2-3* 3.1 on 
an OS/2 2.1 NetWare requester from a 
Novell 3.11 server, I get this message: 
Cannot run in OS/2 compatibility 
box . Is there any way to get Lotus 
1-2-3 3.1 to run from the file server 
on the requester, or do I need to 
make Lotus 1-2-3 3.1 a local applica¬ 
tion on all the machines? 

You must create a program object with 
specific DOS settings to run Lotus 
1-2-3 3.1. You must also create a batch file 
called LOTUS. BAT that sets up an envi¬ 
ronment in which to run Lotus 1-2-3 31. 
The LOTUS. BAT file should read as fol¬ 
lows: 

@ECH0 OFF 
CLS 

PROMPT $P$G 

PATH^C:\123R3 (or appropri¬ 
ate path) 

SET 123MEMSIZE=2048 

123.EXE (last line of file) 

Enter C:\123R3\L0TUS.BAT in the “Path 
and file name:” field for your Lotus pro¬ 
gram object. Specify the DOS settings 
shown in Figure 1 for this object: 

Also in the “Path and file name:” field, 
specify the path to the LOTUS. BAT file 
that is located on the server. For example. 


D0S„HIGH ON 

D0S_VERSI0N INSTALL.EXE.3.40.255 

123.EXE.3.40.255 
LOTUS.EXE.3.40.255 
123D0S.EXE.3.40.255 
ZAP.EXE.3.40.255 
INS.EXE,3.40.255 

DPMI_MEM0RY_LIMIT 4 OR HIGHER 

Figure 1. DOS Settings 




Disk System Limits: 


64 volumes per file server 

Maximum of 32 hard disks per volume (gives a maximum of 2,048 hard disks) 
2,097,152 directory entries per volume 
32 Terabyte maximum volume size 
32 Terabyte maximum addressable disk storage 


File System Limits: 


100,000 concurrent open files per server 
4 GB maximum file size 


Other Limits: 


4 GB addressable RAM 

Figure 2. NetWare File Serve System Limits 


if Lotus 1-2-3 3.1 is installed on the serv¬ 
er’s D: drive, which is seen by the client 
as the K: drive, then specify the following 
in the “Path and file name:” field: 

K:\123R3\L0TUS.BAT 

We want to put an 8 GB to 20 GB file 
under dBase IIP running on a 
NetWare server. Is this file size advis¬ 
able? 

We also have LANRES/MVS. Do file 
restrictions, if any, apply when the 
direct access storage device (DASD) is 
actually host DASD? 

The maximum file size for a NetWare serv¬ 
er is 4 GB. An 8 GB to 20 GB database 
might work, provided none of the data¬ 
base files are larger than 4 GB; however, 
an 8 GB to 20 GB single file will not work. 

Figure 2 shows the system limits for a 
NetWare file server (3.11 or 4.0). 

Because of the way NetWare accesses files, 
the restriction applies even if it is on host 
DASD. Its access method is very much like 
AIX in that it uses a set of pointers to 
disk blocks that are stored in the directo¬ 
ry entry for each file. While this imple¬ 
mentation imposes a limit of 4 GB on a 
file, it also allows for very efficient file 
storage (especially for sparse files). 

We are going to migrate from OS/2 
2.0 to OS/2 2.1. We are running 
NetWare Requester 2.0 right now to 
access a 3.11 server. Will NetWare 


Requester 2.0 work with OS/2 2.1, or 
do we have to use NetWare Requester 
2.01 in the OS/2 2.1 environment? If 
we must have NetWare Requester 
2.01, does it come with new utility 
diskettes? The 3.11 server already 
has the utility diskettes’ files that 
were copied from the utility diskettes 
that came with NetWare Requester 2.0. 

You must use NetWare Requester 2.01 
with OS/2 2.1. The older version of the 
Requester does not work reliably and is 
not supported with OS/2 2.1. 

There are no new utility diskettes for the 
new requester. The version you are using 
now will work fine. 

What are the software and hardware 
requirements, in addition to NetWare 
3.11, for FLeX/IP*? 

Hardware requirements include a Novell- 
certified 80386- or 80486-based server 
with at least 4 MB of RAM plus at least 
3 MB of free space on the system volume 
where NetWare FLeX/lP is to be installed. 
The software requirement is NetWare 3.11 
or above. 

NetWare FLeX/lP is a set of TCP/IP utili¬ 
ties implemented as NLMs. These modules 
must be loaded on a NetWare 311 or 
above server. The TCP NLM included in 
NetWare 3.11 and above must also be 
loaded and running on the server. The 
client UNIX system must support TCP/IP, 
FTP (File Transfer Protocol), LPD (Line 
Printer Daemon), and the X Window 
system. 


We are going to install NetWare 3.11 
on a DOS machine. We are going to 
have OS/2 workstations. What soft¬ 
ware is necessary to make the OS/2 
machines be workstations? We have 
OS/2 2.0 with Network Transport 
Services/2 (NTS/2) with the OS/2 
Requester software in it. 

You will need the NetWare Requester for 
the version of OS/2 you are using. The 
requester for OS/2 2.1 is NetWare 
Requester 2.01. The other requester ver¬ 
sions correspond to the other OS/2 
versions. 

To install the NetWare requester on a 
machine with NTS/2: 

1. Run LAN Adapter and Protocol 
Support (LAPS) again and enable 
NetWare support. 

2. Install the NetWare Requester for 
OS/2 2.x. Choose the native LAN 
adapter driver (TOKEN for token¬ 
ring). 

3. Run NWFIXUP (located in the 
IBMCOM subdirectory). This will 
arrange some of the drivers in the 
CONFIG.SYS. (It will REM out 
the native LAN adapter driver and 
put in the OD12NO I driver). 

We just ordered NetWare for SAA* 1.3 
and would like to have a list of PS/2s 
that support the product. Can you 
help? 

According to the NetWare for SAA 1.3 
Rules of Thumb manual (part of the 
NetWare documentation), the following 
machines have passed Novell’s in-house 
testing: 

PS/2 70 386 
PS/2 70 486 
PS/2 80-071 
PS/2 80-111 
PS/2 Model 95 

While NetWare for SAA will generally run 
on any machine that supports NetWare 
3.11, you should contact (800) NETWARE 
(638-9273) for the most current list of 
supported machines. 
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Corrective Service information 


Figure 1 shows maintenance release levels 
for the listed products. This information 
is effective as of December 3, 1993. To 
order all service packages-except for the 
OS/2 2.0 and OS/2 2.0 Toolkit 
ServicePaks*-call IBM Software Solution 
Services at (800) 992-4777. For the 
OS/2 2.0 ServicePak (XR06100) or the 
IBM Developer’s Toolkit for OS/2 2.0 
ServicePak (XR06l 10) on diskettes or CD- 
ROM, call (800) 494-3044. Most OS/2 ser¬ 


vice packages are also available electroni¬ 
cally from the following sources: 

• OS/2 Bulletin Board Service (BBS): 
Once connected, select Option 2. 
(Corrective services are also listed 
under the General category on the 
IBMLink BBS.) To subscribe to the 
OS/2 BBS, call (800) 547-1283. 

• IBM Personal Computer Company 
(PCC) BBS: Call (919) 517-0001. 


Service packages are located in 
Directory 4. 

CompuServe: Download service 
packages from the IBM OS2 FORUM 
library (GO IBMSERV). 

Internet: Do an anonymous FTP from 
software.watson.ibm.com. Service 
packages are located in the 
/PUB/0S2 directory. 


Praduct/Component 

Release 

CSD Level 

PTF 

Number 

Change 

Date 

Comments 

OS/2 Standard Edition 

1.3 

XROS150 

XROS150 

2-10-93 


OS/2 Extended Edition 

Operating System 

Presentation Manager 

REXX 

User Profile Management 
Communications Manager 

Database Manager 

LAN Requester 

LAN Server 

1.3 

WR05200 

WR05200 

5-12-93 

WR05200 replaces WR050S0, which can no 
longer be ordered on diskette. 

OS/2 

2.0 

XR06100 

XR06100 

9-1-93 

XR06100 replaces XR060S5. 

OS/2 Toolkit 

2.0 

XR06110 

XR06110 

9-1-93 



1.3 

XR05053 

XR05053 

3-23-92 


OS/2 LAN Server/Requester ServicePak 
Service/Requester 

Fault Tolerance 

User Profile Management (UPM) 

2.0 

IP06030 

1P06030 

4-2S-93 


3.0 

IP07001 

IP20086 

10-7-93 


LAN Server/DOS LAN Requester SelectPak 

3.0 

1P07003 

IP07003 

7-28-93 

Diskettes not available. Download from 
one of the BBSs. 

LAN Server HPFS 

3.0 

IP07005 

IP07005 

11-2-93 

IP0700S requires IP07001 be applied to 
system. IP0700S is not for LAN NetView users. 
Diskettes not available. Download from one of 
the BBSs. 


Figure 1. Maintenance Release Levels 
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Product/Component 

Release 

CSD Level 

PTF 

Number 

Change 

Date 

Comments 

LAN NetView Prerequisite 

1.0 

IP07006 

1P07006 

: 11-8-93 

1P07006 is a prerequisite before applying 





f 

1 

1 

i 

LAN NetView. It contains IP07005 plus fixes 
for OS/2 2.x and DB2/2. Requires WR07010 
applied with DB2/2 and XRO 6 IOO applied 
with OS/2 2.0. Diskettes not available. 






1 

Download from one of the BBSs. 

()S/2 Network Transport 

1.0 

WR07020 

WR07020 

10-1 

1 - 93 ! 

Diskettes not available. Download from one 

' Services/2 SelectPak 






of the BBSs. 

OS/2 LAN Adapter and 

2.0 

WR07020 

WR07020 

10-11-931 

Diskettes not available. Download from one 

Protocol Support SelectPak 





1 _ 

of the BBSs. 

OS/2 Extended Services 

1.0 

WR06035 

WR06035 

ii-j 

ilf3; 

Supersedes WRO 6 OOI, WR06002, WRO 6 OO 3 , 

Database Manager ServicePak 




1 1 

r , 

WR06004, WR06014, and WR06015. 

Database Manager Engine DB2/2 

1.0 

WR07010 

WR07010 

M 

^ 3 ; 

Diskettes not available. Download from 
one of the BBSs. 







Database Manager DB2/2 Query Manager 

1.0 

WR07012 

WR07012 

; 8-2$^)3 


DDCS/2 

2.0 

WR07011 

WR07011 

8-29^ 


Extended Services 

1.0 

WR06025 

WR06025 

'ii^iNi 


Conununication Manager 

ServicePak 




, i 
1 ' 



3270, 5250 Emulation 

CM SNA 




1 

! 



Communications Manager/2 

Version 1.01 ServicePak 

1.00 

WR06050 

WR06050 

3 

GT) 

:[_ 

Available only on diskette. 

DOS 

4.0, 4.01 

UR35284 

UR35284 

9-16^1 



5.0 

UR37387 

UR37387 

9 - 22.92 


PC/3270 

1.01 

2012 

IP00832 

11-21-91 


PC/3270 (DOS) 

2.0 

3005 

1P00874 

329 m 



3.0 

[ 7002 j 

IP20006 

9 - 27-93 


PC/3270 (Windows) 

2.0 

4002 

1P00841 

4 - 1*792 



3.0 

6004 

1P20014 

10-22-93 


PC/3270 Emulation, Entry 

1.22 

2201 

UR29500 

3-M 

ip"' 



2.0 

N/A 

N/A 

N/A 


PC LAN Program _ 

1.33 

, 3301 

1P00249 

5-1^0 


1 

1.34 


, IP00755 

6-2^r 



C Set/2 Compiler 


Workstation Program (WSP) | 1.1 

Figure 1. Maintenance Release Levels (Continued) 


XR06150 

UR23217 


6 - 2^3 

11489 
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Copying or reprinting material from this maga¬ 
zine is strictly prohibited without the written 
permission of the editor. Tides and abstracts, 
but no other portions, of information in this 
publication may be copied and distributed by 
computer-based and other information-service 
systems. 

IBM believes the statements contained herein 
are accurate as of the date of publication of this 
document However, IBM hereby disclaims all 
warranties as to materials and workmanship, 
either expressed or implied, including without 
limitation any implied warranty of mer¬ 
chantability or fitness for a particular purpose. 
In no event will IBM be liable to you for any 
damages, including any lost profits, lost savings, 
or other incidental or consequential damage 
arising out of the use or inability to use any 
information provided through this service even 
if IBM has been advised of the possibility of 
such damages, or for any claim by any other 
party. 

Some states do not allow the limitation or exclu¬ 
sion of liability for incidental or consequential 
damages, so the above limitation or exclusion 
may not apply to you. 

This publication could contain technical inaccu¬ 
racies or typographical errors. Also, illustrations 


The following items, noted with an asterisk 
(*) in the magazine’s text, are trademarks or 
registered trademarks of their respective 
companies or organizations. 

AIX, AnyNet/2, AS/400, CICS, C SET/2, CUA, 
DATABASE/2, DB2/2, Extended Services, 
ImagePlus, LAN Streamer, MMPM/2, 
Multimedia, NetView, NetView/6000, 
NetFinity, OS/2, Presentation Manager, 
PROFS, PS/2, RISC Systeni/6000, SAA, 
Ultimotion, ValuePoint, Workplace Shell; 
all of International Business Machines 
Corporation 

AppleTalk and Macintosh; both of Apple 
Computer, Inc. 

COMDEX; The Interface Group, Inc. 

Compaq; Compaq Computer Corporation 


contained herein may show prototype equip¬ 
ment Your system configuration may differ 
slighdy. 

IBM has tested the pn)grams contained in this 
publication. However, IBM does not guarantee 
that the programs contain no errors. 

This information is not intended to be a state¬ 
ment of direction or an assertion of future 
action. IBM expressly reserves the right to 
change or withdraw current products that may 
or may not have the same charaaeristics or 
codes listed in this publication. Should IBM 
modify its products in a way that may affect the 
information contained in this publication, IBM 
assumes no obligation whatever to inform any 
user of the modifications. 

Some of the information in this magazine con¬ 
cerns future products, or future releases of 
products currently commercially available. The 
description and discussion of IBM’s future 
pnxlucts, performance, functions, and availabili¬ 
ty are based upon IBM’s current intent and are 
subject to change. 

IBM may have patents or pending patent appli¬ 
cations covering subject matter in this 
document. The furnishing of this document 
does not imply giving license to these patents. 


CompuServe; CompuServe Inc. 
dBASE III; Borland International Inc. 

Dell; Dell Computer Corporation 
Ethernet; Xerox, Inc. 

FLeX/IP, Novell, NetWare; all of Novell, Inc. 
Hitachi; Hitachi Corporation 
IEEE; Institute of Electrical and Electronic 
Engineering 
Internet; Internet, Inc. 

Lotus 1-2-3; Lotus Development Corporation 
Mathcad; MathSoft, Inc. 

NEC; NEC Technologies Inc. 

Norton and Norton Utilities; both of Symantec 
Corporation 

Oracle; Oracle Corporation 
OSF and Open Software Foundation; both of 
Open Software Foundation, Inc. 

PC EXPO; Bruno Blenheim, Inc. 

ProAudio Spectrum 16; Media Vision 


It is possible that this material may contain ref¬ 
erence to, or information about, IBM products 
(machines and programs), programming or ser¬ 
vices that are not announced in your country. 
Such references or information must not be con¬ 
strued to mean that IBM intends to announce 
such products, programming, or services in 
your country. 

IBM may use or distribute any of the informa¬ 
tion you supply in any way it believes appropri¬ 
ate without incurring any obligation whatever. 

Publication of advertising material in this maga¬ 
zine does not constitute an expressed or 
implied recommendation or endorsement of 
IBM of any particular product, service, compa¬ 
ny, or technology. IBM takes no responsibility 
whatsoever with regard to the seleaion, perfor¬ 
mance, or use of any advertised pnxlucts. All 
understanding, agreements, or warranties must 
take place direcdy between the vendor and 
prospective users. 

All specifications are subjea to change without 
notice. 


PRODIGY; Prodigy Services Company 
Smalltalk; Digitalk, Inc. 

Sony; Sony Corporation 
Sound Blaster; Creative Labs, Inc. 

Sybase; Sybase Inc. 

Toshiba; Toshiba Corporation 
UNIX; X/Open Co., Ltd. 

Windows NT, Windows, Video for 
Windows, Microsoft Word, Microsoft; all of 
Microsoft Corporation 
X Windows; Massachusetts Institute of 
Technology 

80386, 80486, 386SLC, i386SX; all of Intel 
Corporation 

SCRABBLE ■ is a registered trademark in the 
United States of Hasbro, Inc. © 1992 Milton 
Bradley Company, a division of Hasbro, Inc. 
Used with permission. 
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These back issues of Persotial Systems Technical Solutions are available to provide valuable information. Indicate tbe desired 
quantity for the issues you want to order and complete the information on the following page. 


November/December 1993 

IBM PC DOS 6.1; More Features than MS-DOS 6.0 

SystemView Information Warehouse DataHub 

Developing DataHub Tools 

Using MMPM/2 to Create Multimedia Applications 

Advanced Client/Server Computing Using the IBM ThinkPad 

Communications Man'ager/2: A New Look 

Oveniew of IBM NetWare 4.01 

OS/2 2.1 Performance Tuning Tips 

September/October 1993 

IBM PSP’s LAN Systems Solutions 

An Introduction to PCMCIA 

PCMCIA Software: The Key to Compatibility 

OS/2 Support for PCMCIA Memory Cards 

Improving Remote Initial Program Load Performance 

Installing and Configuring CM/2 1.0 

Writing CID-Enabled Applications 

Integrating LAD/2, CM/2, and DB2/2 with IBM LAN NetView Start 
DB2/2-DB2 Comes to the Desktop 

July/August 1993 

OS/2 2.1-Everything You Wanted It to Be imd More 
Using REXX to Customize the Workplace Shell-Part II 
Client/Server Application Development with OS/2 and CICS/ESA 
Upgrading to OS/2 LAN Server 3.0-Advanced 
Developing OS/2 LAN Server Services 

PCMCIA PC Cards Provide Expandability and Network Interfacing 
Using the IBM ThinkPad with OS/2 and CM/2 

April 1993 

XGA-2: Improving on a Good Thing 

IBM Personal Software Products: Product Line Update 

Using RF^X to Customize the Workplace Shell 

OS/2 Distributed Systents Management with LAN NetView 

Priming and Querying Your Start Network 

Multimedia Applications on IBM Token-Ring LANs 

OS/2 2.0 Print Tips 

Testing OS/2 PM Applications 

Accessing a Remote AS/4()0 Using OS/2 Extended Services 
Vinis Information and Protection 
Migrating from APPC/PC to Networking Services/DOS 
OS/2 2.0 Resources 

OS/2 32-Bit Application Migration Workshops 
IBM OS/2 Pnxlucts Available on CD-ROM 

January 1993 

PS/2 Desktop Security 

IBM 486SLC2: System Performance Implications 
Micro (Channel Developers Association 
Trackpoint II: The In-Keyboard Pointing Device 
Why OS/2 2.0? 

OS/2 Distributed Systems Management 

CID: Remote OS/2 Configuration. Installation, and Distribution of 
PC Software 


Start/2: Putting the Configuration into CID 
LAN Server 3.0: New Thresholds in High-Performance Network 
Software 

The Future of IBM LAN Network Management 
Understanding and Using the Workplace Shell 
Distributed Processing: A Case Study 
Parallel Port Protocols 

Developing OS/2 PM Applications with Micro Focus COBOL 
OS/2: How' /Vbout Notelxxiks? 

Loadable ABIOS 

October 1992 

Exploring File Server Performance 
PS/2 3.5*lnch Rewritable Optical Drive 
Pnigramming the XGA Video POS Registers 
Video Monitoring on Personal Computers 
Memory Address Space 

OS/2 2.0 Installation and Performance Considerations 

OS/2 2.0 Application Support 

Cleaner Installation of Applications Under OS/2 

Creating Resizable Pushbuttons 

Configuring Parallel Ports for OS/2 

Performance Characteristics of ES 1.0 Database Manager 

AlertVlEW 

Screen Reader/2 

July 1992 

IBM PS/2 Server 295: New Thresholds for Client/Server 
Networking 

Comparing Architectures: Micro Channel and EISA (Part 2) 
Synergy by Design 
Pen-Based Computers 

Why Doesn’t My Portable’s Battery Last Longer? 

Planning Guidelines for Token-Ring Cabling 
Installing and Migrating Applications in OS/2 2.0 
Printing Under OS/2 2.0 

Installing the IBM 4029 LaserPrinter Under OS/2 1.3 
Serviceability T(M)1 s in OS/2 2.0 
Online Communication Using the OS/2 2.0 PM Terminal 
IBM Extended Services Database Manager 
NetWare for SAA 

Using the IBM DOS 5.0 Driver EMM386.EXE and Upper 
Memory 

The Solutions Evaluation Tool 

April 1992 

Comparing Architectures: Micro Channel and EISA 
Portable Computer Trends and Direaions 
LCD Piuiel Technology 
The OS/2 Vtbrkplace Shell 
New .applications in OS/2 2.0 
Unattended Installation of OS/2 2.0 
OS/2 (k)mmunications Manager Trace Events 
IBM iuid Novell LAN Software Coexistence 
IBM 8209 LAN Bridge Connects Ethernet Clients to Novell and 
IBM Servers 
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Backup and Restore in an IBM NetWare Environment 
The DOS Protected-Mode Environment 
DOS Disk Management 

Customizing Alphanumeric Screen Dimensions 

January 1992 

Additions to the IBM PS/1 Family 

IBM LaserPrinter 4029 Series Print Quality Enhancements 

OS/2 2.0: The Integrating Platform 

Multiple Virtual DOS Machines 

IBM OS/2 LAN Server 2.0 

OS/2 2.0 Memory Maiii^ement 

Coding for Performance Under OS/2 Version 2.0 

Extending the Funaions of OS/2 REXX 

Proteaing User Exits Under OS/2 1.x 

GDDM-OS/2 Unk 

IBM Upgrade Enhanced Install Utility/DOS 5.0 
Advanced Peer-to-Peer Networking: An Overview 
Using IBM SAA Networking Services/2 
The AAI Family of Products 
Securing the Enterprise Workstation 

Issue 4,1991 

Power Factor Non-Linear Loads and the Power Distribution 
System 

Database Manager: Highlights and Direction 

OS/2 Conmiunications Manager 

Improving OS/2 Application Performance 

Creating PM Windows with Dialog Templates 

REXX Program for OS/2 LAN Server 

Micro Focus COBOL/2 and the DOS Database Requester 

IBM DOS 5.0 Faas and Features 

IBM DOS 5.0 Upgrade 

DOS 5.0 Performance Improvements 

DOS Memory Management Facilities 

Disk Caching Under DOS 

NetWare Client-Server Interaction 
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Transmission 
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Understanding an OS/2 CONFIG.SYS File 
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OS/2 EE 1.2 Competitive Performance 
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An entire of hi^ quality Ethernet 

adapter cards at astonishing affordable prices! 

We know it’s hard to believe, but what you see 
on this page is the truth. Allied Telesis, the company 
that led the cost performance revolution in micro 
transceivers and repeaters, is doing it again with sfac 
new adapter cards for your Ethernet LANs. The result 
is uncompromising quality, truly dedicated support 
and more features for a lot less money. 

But don’t take our word for it Here are the vitals: 

1500 Family 

•16 bit PC/AT bus •Software controlled jumpers 

• DMA bus master card • 4 diagnostic LEDs 

• lOBASE-T (DTP) • Novell NE1500T 

support and NE2100 compatible 


1700 Famity 

• 16 bit PC/AT bus • Software controlled jumpers 

• 4 diagnostic LEDs • lOBASE-T (DTP) / 

•32K on-board RAM Type 1 (STP) support 

Plus full IPX, ODI and NDIS driver support, a fiee 
support hot-line, lOBASE-T, 10BASE2 and FOIRL media 
support, and lifetime warranties! 

No tricks, just the truth. With 
quality and affordability like 
this, you owe it to your 
network to take a closer 
look at ATI adapter 
cards. Phone us today 
at 1-800-424-4284, 

Dept #P50. 



Allied Telesis 

575 East Middlefield Road 
Mountain View, California 94043 
1-800424-4284 (US & Canada) 

Tel: 415-964-2771 Fax: 415-964-8250 


University discounts available. Allied Telesis products are GSA listed. 

Freight charges not included, minimum quantities may apply. Please phone us for the nearest participating US or Canadian distributor or reseller offering volume pricing on over 100 ATI network 
building blocks. © /Vllied Telesis 1992. 


Please circle #24 on reader service card. 
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ven a free memory manager may not be 
a bargain—especially if it can't give you 
all the memory you need. 

Introducing QEMM 7 
The Memory Manager 
Worth Paying For 

The newest version of QEMM, version 1, 
pioneers new ways of using the critical area 
between 640K and 1024K. It optimizes this 
area, taking into account the many drivers that 
need more memory at start-up than when 
running; instantly calculating millions of 
possible memory configurations to find still 
more memory for your applications> TSRs and 
utilities to use. 

Instant Riches 

what does more memory mean in a practical 
sense? Simply that your DOS and MS 
Windows programs run faster smoother and 
more reliably. It means you can continue to 
add valuable utilities drivers TSRs and new 
capabilities to your PC. Whether it's workhorse 
drivers like LAN utilities and fax drivers; 
productivity-enhancers like disk caches and 
disk compressors; or fun and 
exciting capabilities like 
sound boards CD ROM 
drivers graphics tablets 
etc. The better your 
memory is managed, the 
mote versatility and flexibility your PC will 
have. QEMM 7 lets you have it all without fear 
of 'out of memory' messages or crashes. 

DOS 6 Giveth; 

DOS 6 Taketh Away 

The best feature of new DOS 6 is the stable of 
utilities it includes. Trouble is they all eat up 
memory. DoubleSpace file compression needs 
43K, Vsafe anti-virus needs 7-45K, Smartdrv 
disk cache needs 28K and even Undelete takes 
10-14K as a resident program. Using 
MemMaker you could easily lose—not gain- 
available 'conventional' memory in DOS 6. 

New QEMM 7 takes the best of the new 


multiple configurations gives you the 
flexibility and ease of setup that you expect. 
(MemMaker doesn't work well with this 
important DOS 6 feature.) 

Page Frame: 
the Key to Your Future 

There's been a lot of jealous talk about our 
patent-pending Stealth technology. Nobody 
else can duplicate its 48-115K gains. 

The key to Stealth is its use of a 64K 
reserved area above 640K called the page 
frame. Besides being used by Stealth, the page 
frame lets Lotus 1-2-3 rZx run larger spread¬ 
sheets and Wordiferfect Sx larger documents. 
It's also used by DESQview for multitasking, 
Novell NetWare, 

IBM LAN Server 
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aQft Horse 
in flie Mouth 


and DECnet for 
reducing the 
network driver 
memory foot¬ 
print, plus games 
for fast action. 
You sacrifice all 
this when other 
memory mana¬ 
gers turn off the 
page frame. 
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Prior versions of QEMM won 
just about every competition in 
sight, as well as remaining the 
il best-selling memory manager 
5 years stramt 


Stealth saves you room to set up your PC with 
a mouse, CD ROM, sound board, a network 
such as Novell NetWare^ create 8-24K of extra 
memory for optimal MS Windows perfor¬ 
mance, use all of DOS 6's memory-hungry 
utilities and still have more than 630K to run 
applications smoothly and safely 

^ Put Your Money 
on a Winnei^^EMM 7 

The new and ever more exciting capabilities 
coming to your PC will all compete for 
memory with your favorite applicationsy TSRs 
and drivers. And that makes QEMM 7 the 
most vital utility you can own. 

Our sevendi-generation memory manager 
is a thoroughbred that helps you get the most 
out of your PC^today^d tomorrow. 

QEMM Users- 

Quarterdeck Office System^ 150 Pico Boulevard, Santa Monica, CA 90405 (310) 392-9851 Fax (310) 314 

Quarterdeck International Ltd, B.I.M. House, Crofton Terrace, Dun Laogjiaire Co. Dublin, Ireland Tel. (353) (1) 284-1444 Fax; (353) (1) 2844380 


OK lOOK 200K 300K 400K 500K 

We tested DOS 6 with and without MemMaker and with 
QEMM 6 and our new QEMM 7 runs away from all of them. 
See details of test conditions listed below. 

DOS 6 features into account finding ways to cut 
memory demands for these utilities by up to 80%, 
ensuring that the all-important memory below 
640K is free for your programs. And QEMM 7's 
seemingly small feature of supporting DOS 6's 


How we got the chart numbers CPU—486/33 ALR Power/business VEKA machine eauipped with 16 megs of RAM and running MS4X)S 6. Comparisoas were done using the follow ing memory managers: QEMM 7, QEMM 6.02, MS-DOS 6 MemMaker. In addition to the driver (or drivers) required by 
each memory manager, the followim drivers, DOS resources and programs were loaded for all comparisons: in the CONFIGSVS file: SETVER.EXE, DOS=HIGH, FlLES=2(j, BUFFERS=10, STACKS=0.0,^SOUNDSYS, SNDBK12SYS, SLCDSYS, DOS SHELL=statement in the AUTOEXEC.BAT file: 
VSAFE, MSCDEX UNDELETE, LSL.COM NE2000.COM IPXODLCOM, NETX OR EMSNETX, MOUSE.COM SMARTDRV.COM PRTSCCAP.COM. ©1993 Quarterdeck Office Systems. Trademarks are property of their respective owners. 


Please circle #25 on reader service card. 


























